사용자의 첫 접속 때 데이터를 새 저장소로 옮깁니다. 동시에 접속하거나 복사가 중간에 멈춰도 안전하게 이어 가려면 어떻게 하나요?

온디맨드 마이그레이션은 접속한 사용자부터 옮기지만 첫 요청에 복사 지연·실패·경합을 넣습니다. not_started → copying → verifying → complete와 needs_repair 상태를 내구화하고 lease·세대로 한 작업자의 진행을 관리합니다. 완료 플래그 하나로 부분 복사와 늦은 워커를 구분할 수 없습니다.

재시도 가능한 복사

작업 ID, 원본 version, checkpoint, 대상 upsert 키를 저장합니다. 중단 뒤 checkpoint부터 재시도하고 건수·체크섬·참조·권한·업무 불변식을 확인한 뒤 complete로 전환합니다. 원본 쓰기를 막을 수 있으면 snapshot 뒤 짧은 cutover를 하고, 계속 허용하면 변경 로그·dual write·충돌 처리가 필요합니다.

lease가 만료된 A의 늦은 complete는 B의 새 generation과 다르면 거절합니다. 대상이 따라잡기 전 라우팅을 바꾸지 않고 사용자에게 무한 대기 대신 진행·재시도 결과를 줍니다. 완료 후 새 저장소 경로, 실패 시 원본·repair queue, 미접속 사용자 일괄 이관·종료를 검증합니다.

첫 접속이 이전 작업을 시작할 때

같은 사용자가 두 기기에서 동시에 접속하면 둘 다 미이전 상태를 읽고 복사를 시작할 수 있습니다. 마이그레이션 행의 상태·세대 조건을 원자적으로 바꿔 하나의 작업 ID를 발급하고, 다른 요청에는 진행 중 상태나 제한된 대기를 반환합니다. 긴 복사를 HTTP 요청 수명에만 묶으면 연결 종료 후 재개가 어려우므로 내구 작업과 사용자 응답을 분리하겠습니다.

페이지별 복사는 안정적인 원본 키와 기준 버전을 이용하고, 대상에는 원본 ID를 고유 키로 upsert합니다. checkpoint를 먼저 전진시키고 데이터 기록이 실패하면 해당 페이지를 건너뛰므로, 대상 반영과 진행 기록의 원자 범위를 정하거나 재실행해도 안전한 페이지 단위 상태를 유지해야 합니다. 단순 count 일치만으로 구매 권리·참조·삭제 상태까지 맞는다고 보지 않습니다.

lease와 쓰기 권위

lease 만료는 옛 워커가 종료됐다는 증거가 아닙니다. 새 세대의 작업이 시작됐으면 옛 워커의 대상 쓰기와 complete 갱신이 실제 저장 지점에서 거절되어야 합니다. 옛 완료 플래그만 막고 옛 데이터 덮어쓰기를 허용하면 새 복사 결과가 오염될 수 있습니다. 모든 쓰기에 세대 조건을 적용하거나 단일 권위 작업자가 게시하는 구조를 사용합니다.

원본 쓰기를 계속 허용하면 스냅샷 기준 이후 변경 로그를 따라잡고 최종 권위 전환 지점을 정해야 합니다. 새 저장소에 쓰기 시작한 후 실패했다고 옛 저장소로 즉시 되돌리면 새 변경을 잃을 수 있으므로 역동기화·보정 절차가 필요합니다. 사용자가 이전 중 계정을 병합하거나 권한을 바꿨다면 원본 버전과 현재 정책을 다시 확인하겠습니다.

접속하지 않는 사용자는 온디맨드만으로 영원히 남습니다. 최종 일괄 이전이나 계정 보관 정책과 레거시 종료 기한을 정하고, 남은 사용자 수·repair 상태·첫 접속 지연·원본 호출률을 관측해야 전체 전환 완료를 판단할 수 있습니다.