Checkpoint는 복구 시작점을 어떻게 옮기는가Checkpoint가 오래된 Redo를 재사용할 수 있는 경계를 만들고, Page LSN과 Doublewrite가 장애 복구에서 맡는 역할을 정리합니다.
COMMIT 직후 서버가 꺼져도 값은 남을까예약 상태 한 건을 따라가며 UPDATE가 Buffer Pool의 Data Page와 Undo Page를 바꾸고 Redo Log를 남기는 과정을 정리합니다.
COMMIT과 Page Flush는 같은 일이 아니다COMMIT과 Dirty Page 저장이 서로 다른 경로로 진행되는 이유와 WAL, STEAL, NO-FORCE가 장애 복구에 미치는 영향을 정리합니다.
COMMIT은 Redo Log의 어디까지 기다리는가Redo Log의 write와 durable flush를 구분하고, COMMIT 목표 LSN과 Group Commit, innodb_flush_log_at_trx_commit 설정의 차이를 정리합니다.
InnoDB는 왜 Redo한 뒤 Undo하는가InnoDB가 Checkpoint 이후 Redo를 먼저 적용하고, 복원한 Undo 정보로 미완료 트랜잭션을 Rollback하는 과정을 정리합니다.
InnoDB의 WAL과 장애 복구UPDATE가 Buffer Pool의 Page를 바꾼 뒤 InnoDB가 Redo Log를 영속화하고, 장애 후 Redo와 Undo로 상태를 복구하는 과정을 정리합니다.
SIGKILL로 확인한 커밋과 롤백MySQL 8.4.10을 SIGKILL로 종료한 뒤 커밋된 변경과 미완료 변경이 어떻게 복구되는지 확인하고, 실험으로 단정할 수 없는 범위를 구분합니다.