PE Notes · DB
ARIES
WAL을 전제로 분석·REDO·UNDO 세 단계로 복구하는 ARIES의 Repeating History, CLR, LSN·더티 페이지 테이블이 재장애에도 멱등인 이유를 정리합니다.
장애 뒤에도 커밋은 남고 미완료는 사라져야 합니다. 는 WAL을 전제로 그 두 약속을 알고리즘으로 적습니다. 현대 InnoDB·PostgreSQL 복구의 뼈대가 이 흐름입니다.
세 원칙
은 데이터 페이지보다 로그를 먼저 디스크에 둡니다. Repeating History During Redo는 커밋 여부와 무관하게 장애 직전 상태를 로그대로 재현합니다. Logging Changes During Undo는 UNDO 자체도 로그로 남겨, 복구 중 다시 죽어도 UNDO를 반복하지 않습니다.
로그 레코드는 , 트랜잭션 ID, 페이지, Redo/Undo 이미지, Prev LSN 체인을 가집니다. 은 UNDO 때 쓰는 보상 로그입니다.
복구 세 단계
Analysis는 마지막 체크포인트의 활성 트랜잭션 표와 더티 페이지 표를 복원한 뒤, 이후 로그로 Winner(커밋)와 Loser(미완료)를 가릅니다. Redo 시작점은 DPT에서 가장 작은 recLSN입니다.
Redo는 그 지점부터 끝까지 순방향으로 적용합니다. 페이지 LSN이 이미 로그 LSN 이상이면 건너뜁니다.
Undo는 Loser를 Prev LSN 체인으로 거꾸로 돌리며 CLR을 남깁니다.
| 단계 | 방향 | 하는 일 |
|---|---|---|
| Analysis | 체크포인트→끝 | Winner/Loser, DPT, Redo 시작점 |
| Redo | 순방향 | 로그대로 페이지 재적용 |
| Undo | 역방향 | Loser 취소, CLR 기록 |
왜 안전한가
복구 중 재장애가 나면 CLR이 “이 UNDO는 이미 했다”를 남깁니다. Steal/No-Force 버퍼 정책과 맞물려, 커밋 전에 더티 페이지가 나가도, 커밋 로그가 있으면 Redo가 살립니다.
