DB가 커밋 성공을 응답한 직후 서버 전원이 꺼졌습니다. 데이터 페이지가 아직 디스크에 쓰이지 않았어도 복구할 수 있는 이유와 필요한 설정은 무엇인가요?

커밋 성공은 데이터 페이지가 최종 위치에 모두 기록됐다는 뜻이 아니라, 장애 복구에 필요한 변경 로그가 약속한 내구 지점까지 기록됐다는 뜻인 경우가 많습니다. 쓰기 전 로그(WAL, write-ahead log)는 데이터 페이지보다 먼저 변경 내용을 로그에 남기고, 장애 뒤 로그를 재생해 커밋된 변경을 복구하게 합니다. 따라서 전원이 꺼졌을 때 페이지가 메모리에만 있어도 로그가 안전하게 보존되면 재시작 복구가 가능합니다.

로그 기록과 페이지 기록의 순서를 구분합니다

변경된 페이지가 더티 상태로 메모리에 있고 커밋 시 WAL 레코드가 디스크 저장장치의 내구 지점에 도달했다면, 복구 과정은 마지막 체크포인트 이후 로그를 읽어 커밋된 변경을 재실행하고 미완료 변경이 유효한 데이터로 보이지 않게 복구합니다. 실제 undo 로그나 MVCC 가시성 처리는 엔진마다 다르므로 모든 DB가 WAL에서 같은 undo를 수행한다고 일반화하지 않겠습니다. 반대로 로그가 DB 버퍼나 운영체제 캐시에만 있고 DB가 이를 내구 기록으로 간주해 응답하면 전원 장애로 최근 커밋을 잃을 수 있습니다. fsync·flush·write-through의 실제 보장은 OS·파일시스템·컨트롤러·저장장치에 따라 달라질 수 있어 DB 설정 이름만으로 단정하지 않겠습니다.

PostgreSQL의 WAL flush, SQL Server의 transaction log flush와 recovery, MySQL/InnoDB의 redo log·flush 설정은 용어와 기본값, group commit 범위가 다릅니다. 어떤 설정은 로그 flush를 지연해 성능을 높이는 대신 허용 가능한 유실 창을 만들고, 어떤 설정은 배터리 보호 캐시 같은 저장장치 계약을 전제로 합니다. 복제본에 전파됐다는 확인도 로컬 로그 내구성과 같지 않으며, 비동기 replica가 승격되면 미반영 로그를 잃을 수 있습니다.

RPO와 복구 절차로 검증합니다

동기화 비용을 줄이려고 커밋을 묶는 group commit은 여러 요청의 로그 flush를 한 번에 처리해 지연을 낮출 수 있지만, 묶인 요청이 기다리는 시간과 장애 시점의 계약을 확인해야 합니다. 체크포인트가 너무 잦으면 쓰기·I/O가 늘고, 너무 드물면 복구 시 재생 로그가 길어집니다. WAL이 있다고 무한정 복구되는 것이 아니라 로그 보존·아카이브와 백업 체계가 필요합니다.

검증은 정상 종료가 아니라 커밋 응답 직후 프로세스 강제 종료, 호스트 전원 중단에 준하는 장애, 저장장치 오류를 재현하고 복구 후 응답된 변경이 존재하는지 확인하는 방식으로 하겠습니다. 커밋 응답 자체가 클라이언트에 도달하지 않은 경우는 DB에 반영됐을 수도, 아닐 수도 있으므로 요청 ID와 결과 조회로 재시도해야 합니다. 서비스가 잃어도 되는 데이터량과 복구 시간 목표를 먼저 정하고, 로그 내구성·백업·복제·클라이언트 멱등성을 하나의 보장으로 뭉뚱그리지 않겠습니다.

복구 검증에서는 ‘커밋 응답을 받은 요청’과 ‘클라이언트가 응답을 받지 못한 요청’을 따로 분류합니다. 전자는 약속한 내구 지점까지 존재해야 하고, 후자는 DB에 있든 없든 요청 ID로 한 번만 확정할 수 있어야 합니다. 로그가 보존돼도 백업 체인이 끊기면 오래된 시점 복구가 불가능할 수 있으므로 WAL 아카이브의 연속성, 체크포인트, 복구 완료 판정과 복구 후 서비스 재개 순서를 함께 시험하겠습니다.