MySQL Undo Log, Redo Log

MySQL에선 2가지 성격의 로그를 사용한다.

Undo Log

특정 레코드의 데이터 변경이 일어나면 MySQL InnoDB는 실제 인덱스 레코드를 수정하고, 수정 전 데이터를 Undo Log에 기록한다. 만약 롤백이 일어난다면 Undo Log를 통해 이전 데이터를 복원한다.

데이터가 커밋되지 않아도, 데이터 수정이 발생하면 Redo Log에 변경 데이터 반영을 위해 기록한다. 하지만 커밋이 되기 전에 실제 테이블에 쓰기를 하진 않는다. 커밋이 되면 Redo Log에 커밋 엔트리 기록이 되면 쓰기 프로세스에 의해 실제 쓰기가 발생하게 되며, 롤백되면 Undo Log로 데이터를 복원한 후 트랜잭션 ID를 통해 Redo Log에 롤백 엔트리를 기록하게 된다.

추가로 Undo Log를 사용하여 이전 데이터를 보관하는 이유는 MVCC와 관련 있다. 이에 대한 내용은 여기에 정리함.

Redo Log

실제 테이블을 수정하기 전에 변경할 데이터들을 모아놓는 일종의 버퍼링(모아놨다 처리)을 위함이라고 볼 수 있다.

테이블도 파일 형태로 Disk에 저장돼 있고, Redo Log도 파일인데 바로 테이블에 반영하지 않고 Redo Log에 저장하는 이유는 왜일까?

• 앞서 언급했 듯 어느 정도 모아놨다가 처리하기 위한 버퍼링의 목적이 있다.

• Redo Log엔 변경 데이터들을 순차 I/O로 기록만 하면 돼서 빠른 쓰기가 가능하지만, 실제 테이블에 반영하기 위해선 해당 위치들을 찾아서 써야 하기 때문에 랜덤 I/O가 발생하여 상대적으로 쓰기가 느리다.