트랜잭션과 복구

DB가 죽었다 살아나도 데이터가 멀쩡한 이유는 딱 하나야 — 수정하기 전에 로그부터 쓰기 때문이지.

WAL(Write-Ahead Logging) 의 원칙은 단순해. 데이터 페이지를 건드리기 전에 변경 내용을 로그에 먼저 기록하는 거야. 로그는 순차 쓰기라 빠르고, 페이지 수정은 랜덤 쓰기라 느리거든. 로그가 디스크에 안전하게 쓰인 후에야 커밋으로 간주하고, 장애가 나면 WAL에서 커밋된 건 재실행(redo), 안 된 건 취소(undo) 해. 이 WAL 기반 복구의 정석이 ARIES야. 분석 → 재실행 → 취소 세 단계로 장애 시점의 상태를 정확히 재현하고, undo 중에 또 죽어도 안전하게 undo 자체를 로그에 남기거든. 체크포인트로 복구 시작점을 앞당기면 복구 시간도 줄일 수 있어.

다른 접근으로 섀도 페이징도 있어. 원본을 안 건드리고 복사본을 수정하다가 포인터만 원자적으로 전환하는 방식인데, 복구가 거의 필요 없는 대신 쓰기 증폭이 루트까지 전파되는 게 대가야. 이 모든 게 동시에 여러 트랜잭션에서 일어나면 동시성 제어가 필요한데, 미리 락을 잡는 비관적(PCC), 일단 실행하고 커밋 때 검증하는 낙관적(OCC), 여러 버전을 유지하는 MVCC 세 가지 접근이 있어. 격리 수준도 Read Uncommitted부터 Serializable까지 스펙트럼이 있고, 대부분의 DB는 Read Committed나 Repeatable Read를 기본으로 쓰지. 그리고 이 모든 걸 뒷받침하는 버퍼 매니저가 디스크 페이지를 버퍼 풀에 캐싱하면서, LRU나 Clock 같은 퇴거 정책으로 뭘 유지할지 결정하는 거야.

---

정리

3장 읽고 기억할 거 세 가지:

1. WAL은 "수정 전에 로그부터 쓴다"는 원칙으로 복구를 보장하고, ARIES는 분석→재실행→취소 세 단계로 장애 후 일관된 상태를 복원한다.
2. 동시성 제어는 PCC, OCC, MVCC로 나뉘며, 격리 수준에 따라 안전성과 성능의 트레이드오프가 결정된다.
3. 버퍼 매니저가 디스크 페이지를 캐싱하며, 더티 페이지의 flush 타이밍이 성능과 복구 시간의 균형점이다.