Redo 로그
일반적으로 리두로그은 ACID에서 지속성을 유지하기 위해 존재하는 것으로 알려져있다.
리두로그는 실제로 다양한 요인에 의해 데이터베이스가 죽으면 리두로그에 기록된 내용을 데이터파일에 적용하도록하고 시작하게 만들 수 있다.
WAL(Write-Ahead Log) 아키텍처
리두로그를 알아보기 전에 먼저 WAL 아키텍처를 알아보려한다. WAL 아키텍처는 insert, update, delete 등 데이터베이스의 변경사항이 실제 데이터베이스를 수정하기 전에 로그 파일에 순차적으로 기록하는 것이다.
이렇게 하는 이유는 디스크 IO에 있어 순차IO가, 랜덤IO보다 훨씬 빠르기 때문이다.

Redo 로그
Redo 로그는 WAL 아키텍처가 적용되어있다. 덕분에 트랜잭션들이 지속성을 보장할 수 있다.
이 Redo로그는 3가지 계층에 따라 다르게 구분될 수 있다.

Logical Redo 계층
- 순차 오프셋 번호(Sequence Number, SN)로 식별한다.
- 개별적으로 단일한 레코드에 대한 수정이 기록된다.
Phyisical Redo 계층
- 로그 순차 번호(Log Sequence Number, LSN)으로 식별한다.
- 물리적으로 일정한 사이즈의 블록 단위로 동작한다.
- 여러 논리적 리두가 포함되지만, 그게 트랜잭션 단위로 묶이는 것은 아니다.
- 여러 트랜잭션을 포함할 수도, 트랜잭션이 갈라질 수도 있다.
- 물리적으로 고정된 크기에 맞춰 논리적 리두를 포함한다.
Log File 계층
- 파일이 고정된 크기로 나눠져있는 형태
- 두 개의 파일이 서로 순환하며 참조하는 형태
- 옵션을 수정하여 해당 파일이
N개로 순환하게 하거나, 사이즈를 조정할 수 있다.
- 기본은
2개, 512MB이다.
- 로그 파일 헤더에 체크포인트(checkpoint offset)가 등록되어있다.
- 체크포인트는 DB의 데이터 파일에 몇 번째 LSN까지 썻는지를 나타낸다.
- 때문에 Active Redo Log는 (가장 최근의 LSN - 체크포인트)가 된다.
innoDB 버퍼풀과 Redo 로그

- 트랜잭션을 커밋하면 해당 트랜잭션에서 사용하던 버퍼 페이지의 정보와 함께 리두 로그 블록에 저장한다.
- 이때 리두 로그 블록이 다 차있다면 기존에 있던 리두 로그 블록에 대한 페이지를 데이터 파일에 작성한다.
- 새로운 리두 로그에 대한 정보를 LSN으로 할당하여 기록한다.
- 체크포인트를 업데이트한다.
Redo log에 대해 깊게 파보셨군요 멋져요
제 DB도 Redo log로 직접 복구해주세요