9장. WAL과 Checkpoint — 절대 잃어버리지 않는 기술

전원이 갑자기 나가도 커밋된 데이터는 살아남습니다. 그 비밀은 "데이터보다 일기를 먼저 쓴다"는 단순한 규칙 — WAL(Write-Ahead Log)에 있습니다.

9.1 WAL — 하나의 로그가 세 가지 일을 한다

WAL(Write-Ahead Log)은 "무슨 변경이 있었는지"를 순서대로 적는 한 줄짜리 일기장입니다. 이 단순한 로그 하나가 PostgreSQL의 세 기둥을 동시에 떠받칩니다.

핵심 불변식은 이름 그대로입니다: 데이터 페이지를 디스크에 쓰기 전에, 그 변경을 설명하는 WAL 레코드가 반드시 먼저 flush되어 있어야 한다. 아래 애니메이션에서 COMMIT 한 번의 여정을 따라가 봅시다.

-- 현재 WAL 쓰기 위치(LSN) 확인
SELECT pg_current_wal_lsn();          -- 예: 16/B374D848

-- 두 LSN 사이 거리(바이트)
SELECT pg_wal_lsn_diff('16/B3800000', '16/B0000000');

-- 이 LSN이 속한 WAL 세그먼트 파일(기본 16MB)
SELECT pg_walfile_name('16/B374D848');  -- 0000000100000016000000B3

9.2 크래시 리커버리 — 일기장으로 되살리기

서버가 갑자기 죽으면 어떻게 될까요? 메모리의 dirty page들은 증발했지만, 커밋된 변경의 일기(WAL)는 디스크에 남아 있습니다. 재시작 시 PostgreSQL은 이 일기를 처음부터가 아니라, 마지막 Checkpoint의 redo point부터 다시 읽으며 재생합니다.

9.3 Checkpoint — 복구 시작점을 앞으로 당기기

WAL만 믿고 영원히 리플레이할 수는 없습니다. WAL이 1TB 쌓였다면 복구에 몇 시간이 걸릴 테니까요. 그래서 주기적으로 "지금까지의 dirty page를 전부 데이터 파일에 내려쓰고, 복구 시작점(redo point)을 현재로 전진"시키는 작업이 필요합니다. 이것이 Checkpoint입니다.

9.4 full_page_writes — 반쪽짜리 페이지 사고 방지

대부분의 디스크는 8KB 쓰기를 원자적으로 보장하지 않습니다. 쓰는 도중 전원이 나가면 "앞 4KB는 새 값, 뒤 4KB는 옛 값"인 torn page(찢어진 페이지)가 남을 수 있죠. WAL 레코드는 "이 페이지의 이 위치를 고쳐라"라는 증분 패치라서, 찢어진 페이지 위에 패치를 얹으면 복구가 오히려 망가집니다.

해결책: Checkpoint 후 페이지가 처음 더럽혀질 때, 페이지 전체 이미지(FPI)를 WAL에 통째로 기록합니다. 복구 시 FPI로 페이지를 먼저 복원한 뒤 그 위에 증분 패치를 적용하면 안전합니다.

# postgresql.conf — 내구성 관련 핵심 설정
full_page_writes = on          # 기본값, 절대 끄지 말 것
wal_compression = on           # FPI 압축 → WAL 양 감소 (v15+: pglz/lz4/zstd)
wal_level = replica            # v10+ 기본. 복제·PITR에 필요

# 쓰기 많은 OLTP 권장 예시
max_wal_size = 16GB
checkpoint_timeout = 15min
checkpoint_completion_target = 0.9

9.5 synchronous_commit — 안전과 속도의 다이얼

커밋 응답을 언제 돌려줄지 선택할 수 있습니다. 안전할수록 느리고, 빠를수록 위험합니다.

-- 손실이 허용되는 로그성 INSERT만 세션 단위로 빠르게
BEGIN;
SET LOCAL synchronous_commit = off;
INSERT INTO event_log SELECT * FROM staging;
COMMIT;   -- fsync를 기다리지 않고 즉시 응답

✍️ 이해도 체크