본문 바로가기
CS/DataBase

redo log(mysql 8.0)

by BK0625 2025. 9. 16.
반응형

 

 

MySQL 8.0 에서 Redo log는 데이터베이스의 성능과 안정성을 모두 잡기 윈한 핵심 장치로 사용된다. 모든 데이터 변경은 실제 데이터 파일보다 Redo log에 먼저 기록되어, 시스템 장애 시에도 데이터를 안전하게 복구하고 평상시에는 빠른 쓰기 성능을 보장한다.

 

  1. 안정성 (Crash Safety) : 커밋(Commit)된 트랜잭션의 변경 사항은 Redo log에 먼저 기록이 보장된다. 따라서 서버 전원이 갑자기 꺼지는 등의 장애가 발생해도, 재시작 시 Redo Log를 보고 미처 데이터 파일에 반영되지 못한 내용을 다시 실행하여 데이터를 복구할 수 있다.
  2. 성능 (Performance) : 디스크의 여러 곳에 흩어져 있는 데이터 파일에 데이터를 쓰는 작업(Random I/O)은 느리다. Redo Log는 변경 내역을 한 파일에 순차적으로 기록(Sequential I/O)하므로 훨씬 빠르다. InnoDB는 일단 빠른 Redo Log에만 기록하고 사용자에게 응답함으로써, 실제 데이터 파일 쓰기를 기다리지 않고 빠른 처리 속도를 제공한다.

 

내부 동작의 핵심 : MTR (Mini-Transaction)

MTR은 InnoDB가 데이터를 변경하는 가장 작은 원자적 작업 단위이다.

  • 개념 : 사용자가 실행하는 BEGIN … COMMIT; 트랜잭션보다 훨씬 작은, 스토리지 엔진 내부의 작업 단위이다. 예를 들어 B-Tree 페이지의 한 레코드를 수정하는 것과 같은 단일 작업이 하나의 MTR로 처리될 수 있다.
  • 역할 : MTR의 가장 중요한 역할은 메모리(버퍼 풀)에 있는 데이터 페이지에 대한 수정 작업이 반드시 통째로 성공하거나 아예 실패하도록 보장(원자성, Atomicity) 하는 것이다.

MTR과 Redo Log의 관계는 절대적이다. MTR은 실제 작업자이며 Redo Log는 그 작업자의 모든 행동을 원자적으로 기록하는 일지이다. MTR이 수행하는 모든 변경 사항은 Redo Log 레코드로 생성되어야만 한다.

 

 

동작 방식 (Write-Ahead Logging)

 

MySQL 8.0의 InnoDB는 Write-Ahead Logging(WAL) 정책을 따른다. 즉, 데이터보다 로그를 먼저 쓴다는 의미이다.

  1. 사용자가 INSERT, UPDATE, DELETE 쿼리를 실행하고 COMMIT을 요청한다.
  2. InnoDB는 해당 데이터를 담고 있는 데이터 페이지를 메모리(버퍼 풀)에서 찾는다.
  3. 페이지 내용을 변경하기 위해 MTR을 시작한다.
  4. MTR은 페이지의 어느 부분을 어떻게 바꿀 것이다라는 내용의 Redo Log 레코드를 생성하여 메모리 상의 Redo Log 버퍼에 기록한다.(이 과정에서 Redo log 파일 기록 완료 직후 사용자에게 COMMIT이 완료되었다고 성공 응답을 보냄)
  5. MTR은 버퍼 풀에 있는 실제 데이터 페이지의 내용을 수정한다.
  6. 페이지 수정이 성공적으로 끝나면 MTR은 내부적으로 커밋되고, 이 때 생성된 Redo Log 레코드가 최종 확정된다.
  7. 사용자 트랜잭션이 최종 커밋 되면, Redo Log 버퍼의 내용이 디스크의 Redo Log 파일로 기록(flush) 된다. (innodb_flush_log_at_trx_commit 설정에 따라 동작 방식이 달라짐)
  8. Redo log 파일에 기록이 완료되면, 작업의 영속성이 보장되었으므로 서버는 사용자에게 성공 응답을 보낸다.
  9. 실제 데이터 파일에 대한 변경은 나중에 백그라운드 스레드가 여유로울 때 처리된다.

 

MySQL 8.0에서의 관리 및 설정

  • 용량 설정 (innodb_redo_log_capacity) : 이 단일 변수로 Redo Log의 전체 용량을 설정한다. 서버 재시작 없이 동적으로 크기 조절이 가능하여 운영이 매우 편리하다.
  • 내구성 제어(innodb_flush_log_at_trx_commit)
    • 1 (기본값, 가장 안전) : COMMIT마다 즉시 디스크에 기록하여 데이터 유실을 완벽하게 방지한다
    • 2 (성능 중시) : OS 캐시에만 기록하고 1초마다 디스크에 동기화한다. OS 장애 시 1초 내 데이터가 유실 될 수 있다.
    • 0 (성능 극대화) : 1초마다 디스크에 기록한다. DB 서버 장애 시 1초 내 데이터가 유실 될 수 있다.

 

장애 복구 시의 역할

서버 장애 후 재시작 시, InnoDB는 Redo Log를 읽어 데이터 파일에 기록된 마지막 시점 이후의 로그들을 다시 실행한다. 이 때 로그가 MTR 단위로 원자적으로 기록되어 있기 때문에, 증간에 끊기거나 손상된 작업이 데이터 파일에 반영되는 일 없이 완벽하게 일관된 상태로 복구할 수 있다.

반응형