수백만 행을 한 번에 갱신하니 로그와 복제 지연이 커집니다. 배치로 나눌 때 어떤 정확성 조건이 달라지나요?

배치 커밋은 잠금·로그·복구 부담을 줄일 수 있지만 전체 작업의 원자성을 여러 부분 완료 상태로 바꿉니다. 먼저 일부만 반영된 상태를 허용하는지와 재시작 기준을 정해야 합니다.

동작 원리와 전제

안정적인 기본키와 처리 기준 시점을 사용해 작은 범위를 갱신하고 마지막 완료 키를 기록할 수 있습니다. OFFSET으로 다음 배치를 고르면 삭제·조건 변화에 따라 행을 건너뛸 수 있습니다. 처리 조건이 바뀌는 행은 버전 검사나 재조사 큐로 다룹니다.

선택과 실패 처리

배치 크기는 고정 숫자를 외우지 않고 로그 생성률·잠금·replica lag·사용자 p99에 맞춰 조절합니다. 한 배치 결과와 checkpoint의 저장 순서가 어긋나면 중복 또는 누락이 생기므로 같은 transaction에 넣거나 재실행에 안전하게 합니다.

구체적인 사례와 검증

status='pending'인 행을 1,000개씩 처리하면서 OFFSET을 늘리면 이미 처리한 행이 조건에서 빠져 목록이 줄어들기 때문에 다음 행을 건너뛸 수 있습니다. 안정적인 키의 다음 범위와 완료 기준을 사용해야 합니다. 특정 행이 계속 실패할 때 전체 배치를 무한 반복할지 그 행만 격리할지도 정합니다. 부분 완료가 허용되지 않는 작업은 새 버전 테이블에 결과를 만들고 검증 후 읽기 포인터를 바꿀 수 있지만 이 경우 동시 쓰기와 역전환이 추가 문제입니다. 배치는 성능 옵션이면서 사용자에게 보이는 원자성·진행률·복구 계약을 바꾸는 선택이라는 점을 명확히 하겠습니다.

중간 종료·동시 삽입·키 변경·한 행 오류와 재개를 시험합니다. 전부 성공한 것처럼 표시하지 않고 처리·실패·보류 수를 공개합니다. 정말 전체 원자성이 필요하면 단순 배치 대신 별도 버전 데이터 생성 후 원자적인 포인터 전환 같은 설계가 필요한지 검토합니다.