PostgreSQL WAL의 선행 기록, 충돌 복구와 복제 조건

PostgreSQL의 Write-Ahead Logging(WAL)은 데이터 페이지 변경을 데이터 파일에 쓰기 전에 해당 변경을 설명하는 WAL 레코드를 영속 저장소에 기록한다는 원칙입니다. 이 규칙으로 매 커밋마다 모든 테이블 페이지를 디스크에 기록하지 않고도, 장애 뒤 로그의 REDO로 데이터 파일을 복구할 수 있습니다. 일반적인 내구성은 WAL이 실제로 안정 저장소에 도달하는 시점과 설정에 달려 있습니다. synchronous_commit, fsync, 저장장치의 flush 동작, 트랜잭션 종류를 무시하고 “모든 커밋은 즉시 영구 보장”이라고 말할 수 없습니다. LSN은 WAL 스트림의 위치를 나타내며 복구·복제 진행을 비교하는 데 사용됩니다.

전문가 관점: PostgreSQL 기여자가 설명하는 체크포인트

PostgreSQL 핵심팀 기여자인 Bruce Momjian의 WAL 발표자료는 WAL 레코드, 충돌 복구, 시점 복구, 물리·논리 복제, 복제 슬롯을 함께 다룹니다. PostgreSQL 문서에 따르면 체크포인트 위치는 pg_control에 저장되며 복구 시 서버는 그 위치의 체크포인트 레코드를 확인한 뒤 WAL을 앞으로 스캔해 REDO합니다. 체크포인트는 “모든 변경이 체크포인트에서 안전 저장되므로 그 전 로그를 즉시 지워도 된다”는 뜻이 아닙니다. 필요한 복구·복제·아카이브 목적의 WAL은 별도 조건으로 유지될 수 있습니다. 복구 시간이 항상 수초~수분이라는 보장도 없으며 로그량, 데이터 크기, I/O, 설정에 따라 달라집니다.

체크포인트 튜닝과 장애 후 작업

체크포인트는 dirty buffer 기록과 WAL 위치 저장을 조정해 crash recovery가 훑을 범위를 제한합니다. 너무 잦은 체크포인트는 쓰기 부하와 full-page image WAL을 늘릴 수 있고, 더 긴 간격은 복구 작업량과 필요한 WAL 보존량을 키울 수 있습니다. max_wal_size는 절대적인 디스크 상한이 아닙니다. 아카이빙 실패, replication slot, 복제 지연 등으로 WAL이 계속 보존되어 예상보다 크게 증가할 수 있으므로 저장 공간 경보가 필요합니다. checkpoint_completion_target 같은 튜닝은 버전과 workload를 기준으로 관측하며 기본값을 무조건 바꾸지 않습니다.

복제·백업·내구성 목표를 구분

스트리밍 복제는 WAL을 standby로 전송하고 재생하지만, 비동기 복제에서는 primary 커밋 직후 장애가 나면 아직 도착하지 않은 최신 트랜잭션을 잃을 수 있습니다. 동기 복제는 설정한 standby 확인 조건을 커밋에 포함할 수 있지만 지연과 가용성 trade-off가 있습니다. replication slot은 소비자가 필요한 WAL을 유지하는 데 도움을 주며, 정지된 consumer가 slot을 붙잡으면 디스크 사용량이 커질 수 있습니다. WAL 아카이빙과 base backup을 조합한 PITR은 운영자가 지정한 시점까지 복구할 수 있지만, 백업·아카이브의 완전성과 실제 복구 절차 검증이 전제입니다. 목표 RPO/RTO를 정하고 pg_stat 모니터링, slot 상한, 아카이브 오류 경보, 정기 복구 연습을 함께 운영하세요.

참고 자료