로깅과 복구

학습 목표

WAL(Write-Ahead Logging) 규칙과 지속성(D)·원자성(A) 과의 관계를 설명할 수 있다.

redo log와 undo log의 역할 차이를 구분할 수 있다.

checkpoint가 복구 시간을 줄이는 이유를 설명할 수 있다.

crash recovery의 분석·redo·undo 단계를 순서대로 설명할 수 있다.

문제 상황

• COMMIT 직후 전원 장애 — 재기동해도 반영돼 있다
  • 버퍼만 쓰고 디스크 페이지는 아직 dirty였을 수 있음
• UPDATE 도중 크래시 — 재기동 후 반쪽 반영이 없다
  • 원자성 — WAL·undo로 롤백
• PostgreSQL pg_wal·MySQL ib_logfile 디스크가 계속 찬다
  • WAL 누적 — checkpoint·아카이브 정책
• checkpoint 많이 돌리면 복구는 빨라지는데 쓰기 부담
  • 트레이드오프
• fsync·synchronous_commit 설정에 따라 성능 vs 내구성이 바뀐다
  • COMMIT 응답 시점 = WAL 내구 시점

앞서 ACID에서 Durability를 WAL로 예고했다. 데드락으로 txn 하나가 롤백되는 것과, 서버 전체가 죽었다 살아나는 복구는 다른 층위다.

1. 왜 로그가 필요한가

데이터 페이지는 버퍼 풀에 먼저 바뀌고, 디스크 반영은 나중(lazy write)이다.

없으면	문제
페이지만 디스크에 쓰기	크래시 시 COMMIT·ROLLBACK 경계 불명
버퍼 flush만	순서 뒤바뀜 — 오래된 페이지가 새 값 덮어씀
로그 없이 복구	어떤 txn까지 반영할지 판단 불가

• 로그 = 순차 append — 디스크 순차 쓰기에 유리
• WAL = 변경 기록을 먼저 내구 저장 → 페이지 flush 이후여도 복구 가능

2. Write-Ahead Logging (WAL)

WAL 규칙 — 데이터 페이지를 디스크에 쓰기 전에, 해당 변경에 대한 로그 레코드가 먼저 디스크(또는 정책상 durable)에 기록돼야 한다.

1. txn: UPDATE page P (buffer pool에서 dirty)
2. WAL buffer에 log record append
3. COMMIT → WAL flush (fsync)
4. 나중에 checkpoint / background writer가 page P flush

단계	내용
Log append	(txn_id, page_id, before, after, …) 순차 기록
COMMIT	해당 txn log가 durable — 클라이언트에 OK
Page write	언제든 나중 — WAL이 진실의 원천

-- PostgreSQL: WAL 위치 확인 (개념)
SELECT pg_current_wal_lsn();

-- durability vs latency
SET synchronous_commit = on;   -- default: wait WAL flush
SET synchronous_commit = off;  -- faster, small window of loss on crash

DB	WAL 저장
PostgreSQL	pg_wal/ (과거 pg_xlog)
MySQL InnoDB	redo log files + undo tablespace

• Group commit — 여러 txn WAL을 한 fsync에 묶어 처리
• Full Page Write (PostgreSQL) — checkpoint 직후 첫 dirty page는 전체 페이지 이미지 WAL — partial page write 방어

3. Redo vs Undo

	Redo	Undo
목적	이미 COMMIT 된 변경 재적용	미커밋 변경 취소
방향	로그 앞으로 → 페이지 복원	로그 뒤로 → 이전 값
언제	크래시 후 durability 회복	크래시 후 atomicity 회복
예	WAL redo record replay	undo chain으로 old value

T1: UPDATE balance 1000 → 900   (not yet COMMIT)
-- crash --
Recovery: UNDO T1  → balance back to 1000

T2: UPDATE ... COMMIT, page still dirty in buffer
-- crash --
Recovery: REDO T2  → re-apply committed change on disk page

• Undo는 rollback·snapshot에도 사용 (MVCC 편)
• Redo는 InnoDB redo log, PostgreSQL WAL — 물리·논리 레코드 형태는 DB마다 다름

4. Checkpoint

Checkpoint — 버퍼의 dirty page를 디스크에 반영하고, 복구 시작점(redo LSN)을 앞당기는 작업.

효과	설명
복구 시간 ↓	재기동 시 스캔할 WAL 구간 축소
WAL 재활용	오래된 WAL segment 삭제·아카이브 (설정에 따라)
비용	flush I/O burst — checkpoint_timeout·max_wal_size 튜닝

--- WAL timeline ---
|---- archived ----|-- since last checkpoint --|-- new writes --|
                   ^ checkpoint record (LSN)

PostgreSQL	의미
checkpoint_lsn	이 LSN 이전 dirty page는 디스크에 반영됨
pg_control_checkpoint()	마지막 checkpoint 정보

• checkpoint 직후 크래시 → redo 구간 짧음
• checkpoint 없이 장시간 운영 → 재기동 redo 오래 걸림

5. Crash recovery 흐름

재기동 시 DBMS는 일관된 상태로 되돌린 뒤 COMMIT 만 반영한다 (ARIES 등 steal / no-force 정책).

단계	이름	하는 일
1	Analysis	checkpoint부터 WAL 스캔 — active txn, dirty page 집합
2	Redo	checkpoint LSN부터 끝까지 — 모든 logged change 재적용 (idempotent)
3	Undo	analysis에서 미완료 txn — 역순 undo

Startup
  → read checkpoint
  → Analysis (who was active?)
  → Redo (replay everything logged)
  → Undo (rollback incomplete txns)
  → accept connections

정책	의미
Steal	COMMIT 전 dirty page를 디스크에 쓸 수 있음 → undo 필요
No-force	COMMIT 후에도 page flush 미룸 → redo 필요

• Redo는 committed + uncommitted 모두 replay 후, Undo로 미커밋 정리
• Idempotent redo — 같은 redo를 두 번 적용해도 결과 동일 (LSN on page)

6. 실무 포인트

항목	권장
COMMIT latency	synchronous_commit·replica 정책 이해
디스크	WAL 전용 SSD·별도 볼륨 (PostgreSQL)
WAL 폭주	max_wal_size, checkpoint, 아카이브·PITR 계획
복구 테스트	백업 + WAL 로 되살리기 연습
앱	COMMIT 후만 외부 부작용(메일·MQ) — 2PC·outbox는 이후 편

-- PostgreSQL: recovery-related settings (reference)
SHOW wal_level;          -- replica / logical for archiving
SHOW archive_mode;
SHOW full_page_writes;

-- InnoDB: flush log at commit (MySQL cnf)
-- innodb_flush_log_at_trx_commit = 1  (full durability)
-- = 2  (OS buffer, crash OK, OS crash risk)

예시·설정 참고는 code/wal-recovery-notes.sql.

7. 정리

• WAL — 로그 먼저 durable → 페이지는 나중 flush 가능
• Redo — COMMIT 반영 복구 · Undo — 미커밋 취소
• Checkpoint — dirty flush + redo 시작점 전진 → 복구 시간 단축
• Recovery — Analysis → Redo → Undo
• MVCC·vacuum·복제 WAL은 다음 편들

다음에 다룰 것

• MVCC와 스냅샷 격리
• 버전 체인, vacuum

---

해당 내용은 Database System Concepts, 7/E (Avraham Silberschatz, Henry F. Korth, S. Sudarshan) 의 내용을 기반으로 합니다.