포스트

카카오 「MySQL InnoDB Log에 대한 이해 - (1)」 리뷰 — 트랜잭션 하나가 어떻게 MTR 여러 개로 쪼개져 Redo Log Buffer에 들어가는가

Tech Blog Review
게시
By August
좋아요 조회 9 분 읽는 시간

원문: MySQL InnoDB Log에 대한 이해 - (1) — kakao tech, 2025-08-11

한 줄 요약

InnoDB의 Redo Log는 WAL(Write-Ahead Log)이다. 데이터 파일을 고치기 전에 “무엇을 고쳤다”를 먼저 로그에 순차로 쓰고, 커밋은 로그가 디스크에 동기화된 시점이며, 실제 데이터 파일 반영은 백그라운드가 나중에 하고, 크래시가 나면 로그로 되살린다. 이 글은 그 로그가 만들어지는 최소 단위인 MTR(mini transaction)을 소스 구조체 수준으로 설명하고, 5.7에서 세션마다 만든 MTR이 뮤텍스 하나를 잡고 전역 Redo Log Buffer에 복사되는 과정을 보여 준다. 2편(8.0의 개선)을 위한 기초편이다.

배경: WAL의 네 가지 조건

원문은 “이것이 있어야 WAL”이라고 넷을 든다.

  1. 변경이 생기면 먼저 WAL에 쓰고, 그다음 디스크에 순차 기록한다.
  2. 커밋 성공의 기준은 WAL이 디스크에 동기화된 시점이다.
  3. WAL의 변경은 나중에 백그라운드가 실제 데이터 파일에 반영한다.
  4. 크래시 시 WAL로 복구해, 데이터 파일에 안 쓰인 변경을 다시 적용한다.

Redo Log의 부품은 둘이다. Redo Log Buffer(메모리, 기본 16MB, innodb_log_buffer_size)와 Redo Log File(디스크, 기본 2개, innodb_log_files_in_group).

기본 흐름

DML로 페이지가 바뀌면 이렇게 흐른다.

  1. Buffer Pool에 페이지를 복사해 거기서 변경한다.
  2. 변경 내용을 MTR 단위로 세션별 메모리에 기록한다.
  3. MTR에 다 기록되면 commit()으로 Redo Log Buffer로 옮기고, 바뀐 페이지를 Buffer Pool의 Flush List에 넣는다.
  4. Flush 이벤트나 Checkpoint 때 Redo Log Buffer가 Redo Log File에 쓰인다. Checkpoint 때는 페이지가 디스크에 쓰이기 전에 로그가 먼저 쓰인다(이것이 Write-Ahead).
  5. 그 뒤 Flush List의 페이지가 데이터 파일로 내려간다.

이 논리는 모든 InnoDB 버전에서 같다. Flush 주기는 innodb_flush_log_at_trx_commit으로 조절한다. 1이면 커밋마다 디스크에 flush(안정성), 0이나 2면 성능 우선. 원문은 이 변수를 따로 꼭 공부하라고 권한다.

핵심: MTR

MTR은 Redo Log가 다루는 가장 작은 작업 단위로, 페이지 하나 또는 몇 개의 변경을 로그에 쓰는 단위다.

  • I/O 작업의 최소 단위다. 사용자 트랜잭션 하나는 여러 MTR로 쪼개진다.
  • 원자적이다. MTR의 변경은 전부 기록되거나 전혀 기록되지 않는다.
  • WAL로 동작한다. 먼저 Redo Log Buffer에, 다음에 스케줄대로 파일에.

MTR로 나누면 트랜잭션 내부 작업을 동시에 진행할 수 있고, 물리적 변경 단위로 기록하므로 논리적 SQL보다 훨씬 작고 효율적인 로그 레코드가 나온다. 로그가 작으면 디스크 I/O가 준다.

구조체 mtr_t. 주요 필드는 m_memo(잠금용), m_log(MTR 로그), m_log_mode, m_state, 더티 페이지 생성 여부, 수정한 테이블스페이스·Undo·System 테이블스페이스 등이다. 로그 모드는 넷이다. MTR_LOG_ALL(기본, redo 저장 + 더티 페이지 Flush List 추가), MTR_LOG_NONE(둘 다 안 함), MTR_LOG_NO_REDO(redo는 안 쓰고 더티 페이지만 Flush List에), MTR_LOG_SHORT_INSERTS(로그 크기 축소). 상태는 INIT → ACTIVE → COMMITTING → COMMITTED.

할당. 세션 메모리의 힙에, 초기 64바이트로 만들고 필요한 만큼 링크드 리스트로 잇는다.

생애 주기. start()(초기화) → 변경 기록 → commit()(Redo Log Buffer로 넘길지 검토 후 수행) → release_resource()(자원 반환). commit 안에서는 취소되지 않으면 execute()가 prepare_write()(버퍼에 쓸 준비, 작업량 계산)와 finish_write()(memcpy로 복사)를 부른다.

UPDATE 하나가 만드는 MTR 셋

UPDATE 쿼리 하나에 MTR이 세 종류 생긴다.

  • Buffer Pool의 데이터 페이지 변경을 담는 MTR
  • Undo 테이블스페이스의 페이지 변경을 담는 MTR
  • 커밋 관련 정보를 담는 MTR

트랜잭션이 시작해 DML을 수행하면 세션 메모리에 MTR을 만들어 start()하고, 변경 정보 중 Undo 관련은 Undo용 MTR에, 일반 페이지 변경은 데이터용 MTR에 저장한다. 쿼리가 끝나면 commit()이 Redo Log Buffer로 넘기고 더티 페이지를 Flush List에 넣은 뒤 release_resource()한다.

번외 둘. Flush List의 더티 페이지는 동기(buf_dblwr_flush_buffered_writes())와 비동기(buf_flush_write_block_now()) 방식이 모두 있고 최종적으로 file_io()로 쓴다. 롤백은 각 쿼리의 MTR이 이미 Redo Log에 들어갔으므로, 되돌리는 변경도 다시 Redo Log에 저장되어야 한다.

5.7: 뮤텍스 기반

5.7의 Redo Log는 한마디로 뮤텍스 기반이다. MTR commit()이 호출되면 먼저 Redo Log Buffer의 뮤텍스를 확보하고, MTR 정보를 버퍼에 쓴 뒤, 뮤텍스를 반환한다. 트랜잭션 전체로 보면 ① MTR → Redo Log Buffer, ② 더티 페이지 → Flush List, ③ Redo Log Buffer → Redo Log File 세 단계이고, 각 단계에서 경합이 있는 자원은 뮤텍스로 확보한 뒤 진행한다. 여러 세션의 MTR이 이렇게 하나의 전역 버퍼에 직렬로 들어간다.

이 지점이 2편의 복선이다. 세션이 많을수록 그 뮤텍스가 병목이 되고, 8.0은 이것을 lock-free로 바꿨다.

읽고 남는 질문

  • MTR이 “물리적 변경 단위”라고 했는데, 페이지 내 오프셋과 바이트를 기록하는 physiological logging인지 순수 physical인지가 구분돼 있으면 로그 크기 논의가 더 정확해진다.
  • MTR_LOG_NO_REDO가 쓰이는 경우(예: 임시 테이블, 인덱스 생성 중)가 언급만 되고 예시가 없다. 언제 redo 없이 더티 페이지만 flush하는지가 궁금하다.
  • innodb_flush_log_at_trx_commit=2에서 OS 캐시에 쓰고 1초마다 fsync하는 동작이 이 글의 4단계 흐름 중 어디에 해당하는지 짚어 주면 초심자에게 더 도움이 됐을 것이다.

한 줄로 가져가기

Redo Log를 이해하려면 “트랜잭션”이 아니라 “MTR”로 내려가야 한다. 트랜잭션은 MTR 여러 개의 묶음이고, 각 MTR이 세션 메모리에서 전역 버퍼로 옮겨지는 순간이 5.7에서는 뮤텍스 하나를 지나가는 병목이다.

시리즈

빅테크 기술 블로그 리뷰

31편 중 9편

이전 시리즈 글 네이버 D2 「CDC 복제 이후 오라클이 느려졌다? child cursor 폭증이 만든 예상치 못한 문제」 리뷰 — 같은 SQL인데 바인딩 타입이 다르면 Oracle은 다른 쿼리로 본다 다음 시리즈 글 카카오 「PostgreSQL to ES: Kafka Connect CDC 파이프라인」 1·2편 리뷰 — 변경이 없어서 디스크가 차고, LSN이 사라져서 스냅샷을 다시 짜야 했던 CDC의 실제 운영 비용
  1. 1 카카오 「실시간 메시징 시스템 개발기」(3편) 리뷰 — Redis에 몰린 부하를 서버로 옮기고, 그 서버를 pprof로 세 번 깎은 이야기
  2. 2 카카오 「추가배포 없이 API의 case 통일시키기」 리뷰 — 받는 쪽이 자기 케이스에 맞춰 알아서 읽게 하면 배포 순서가 사라진다
  3. 3 카카오 「MySQL DATETIME, TIMESTAMP 데이터 타입에 대한 분석」 리뷰 — 바이트 단위 저장 구조부터 아직 안 고쳐진 Y2K38까지
  4. 4 네이버 D2 「6개월 만에 연간 수십조를 처리하는 DB CDC 복제 도구 무중단/무장애 교체하기」 리뷰 — 복제·검증·복구를 셋으로 나누고, 옛 도구와 새 도구를 서로 모르게 같이 돌린 전환
  5. 5 카카오 「MySQL ALTER DDL 수행 방식에 대한 이해」 리뷰 — Copy·In-Place·Instant는 '무엇을 복사하느냐'보다 '언제 Exclusive 메타 락을 잡느냐'로 구분된다
  6. 6 카카오 「MySQL Orchestrator 기반의 새로운 HA 표준 개발기」 리뷰 — 10년 멈춘 Perl 도구를 떠나 Raft 클러스터로, 그리고 slave_net_timeout 한 줄
  7. 7 카카오 「MySQL Ver. 8.0 New Feature: Instant DDL Algorithm에 대한 이해」 리뷰 — 컬럼을 0.01초에 추가하는 대가는 '읽을 때마다 버전을 대조하는 것'이다
  8. 8 네이버 D2 「CDC 복제 이후 오라클이 느려졌다? child cursor 폭증이 만든 예상치 못한 문제」 리뷰 — 같은 SQL인데 바인딩 타입이 다르면 Oracle은 다른 쿼리로 본다
  9. 9 카카오 「MySQL InnoDB Log에 대한 이해 - (1)」 리뷰 — 트랜잭션 하나가 어떻게 MTR 여러 개로 쪼개져 Redo Log Buffer에 들어가는가
  10. 10 카카오 「PostgreSQL to ES: Kafka Connect CDC 파이프라인」 1·2편 리뷰 — 변경이 없어서 디스크가 차고, LSN이 사라져서 스냅샷을 다시 짜야 했던 CDC의 실제 운영 비용
  11. 11 LINE 「기획서 없이 내재화하기: 검증 로직으로 동일함을 증명하다」 리뷰 — 블랙박스는 입력과 출력만 정의하면 통계로 같음을 증명할 수 있다
  12. 12 뱅크샐러드 「게임을 만들 때 데이터 정합성을 유지하는 법 (feat. 낙관적 락)」 리뷰 — 같은 WHERE version 조건인데, 충돌한 요청을 어떻게 하는가에서 갈리는 두 설계
  13. 13 우아한형제들 「Spring Batch와 Querydsl」 리뷰 — offset을 버린 Reader가 21분을 4분으로 만든 이유, 그리고 그 Reader가 답하지 않는 두 가지
  14. 14 네이버 D2 「테스트는 어떻게 좋은 코드를 만드는가(feat. 험블 객체 패턴)」 리뷰 — 목이 많아지는 것은 테스트의 문제가 아니라 설계의 신호
  15. 15 당근 「QR을 찍으면 무슨 일이 벌어질까? 당근페이 현장 결제의 모든 것」 리뷰 — 카드망을 빌려 7주 만에 낸 결제와, 그 글이 다루지 않은 승인 응답이 사라지는 순간
  16. 16 네이버 D2 「스마트스토어센터 Oracle에서 MySQL로의 무중단 전환기」 리뷰 — 두 DB에 동시에 쓰되 한쪽 실패는 무시하고, 읽기 트래픽을 복제해 성능을 재고, 6개월간 불일치를 0으로 만든 과정
  17. 17 야놀자 「RESTful API validation 자동화 하기」 리뷰 — 인터페이스 하나에서 검증·문서·타입을 뽑는 이유, 그리고 자동화가 없으면 누락이 필연이라는 문장
  18. 18 카카오 「MySQL Json 데이터 타입의 저장 구조와 성능 비교」 리뷰 — 통째로 넣고 통째로 꺼내면 TEXT, 키로 파고들면 JSON
  19. 19 LINE 「도메인에 의존하지 않는 채팅 플랫폼은 어떻게 만들었을까?」 리뷰 — 사용자를 모르는 채팅 플랫폼, 웹으로 만든 클라이언트, SOFT STOP으로 갈아 끼우는 챗봇 시나리오
  20. 20 카카오페이 「MSA 환경에서 네트워크 예외를 잘 다루는 방법」 리뷰 — Unknown을 타입으로 만든 글과, Unknown을 상태로 저장한 프로젝트가 갈리는 지점
  21. 21 카카오 「메시징 서버의 스트레스 테스트 노하우와 AI가 덜어 준 부분」 리뷰 — 지표를 네 층으로 내려가 읽는 법, 그리고 LLM에게 맡긴 것과 맡기지 못한 것
  22. 22 네이버 D2 「일 3,000만 건의 네이버페이 주문 메시지를 처리하는 Kafka 시스템의 무중단 전환 사례」 리뷰 — 두 벌로 발행해 대조한 검증기와, 발행 제어 키를 파티션 키와 같게 둔 이유
  23. 23 카카오 「잃어버린 리포트를 찾아서: 카카오 메시징 시스템의 경쟁 조건 문제와 안티 패턴 제거 과정」 리뷰 — 벤더가 8ms 만에 리포트를 보냈고, 우리는 101ms짜리 트랜잭션 안에 있었다
  24. 24 컬리 「컬리의 입고 시스템이 외부 인입 데이터를 안전하게 동기화하는 방법」 리뷰 — 145회 재시도가 맞는 도메인과 재시도를 금지한 도메인, 그리고 발행부와 수신부가 각자 책임지는 구조
  25. 25 네이버 D2 「@RequestCache: HTTP 요청 범위 캐싱을 위한 커스텀 애너테이션 개발기」 리뷰 — 캐시의 수명을 '요청 하나'로 맞추면 TTL 고민이 사라진다, 그리고 @RequestScope가 안 되는 이유
  26. 26 무신사 「Kafka와 Strimzi를 이용하여 6개의 도메인을 하나의 도메인으로 합쳐보았습니다」 리뷰 — 배치 없이 CDC와 Kafka Streams로 옮긴 결정, 그리고 통합 모델이 원본과 같다는 것을 누가 확인하는가
  27. 27 쿠팡 「대용량 트래픽 처리를 위한 쿠팡의 백엔드 전략」 리뷰 — 캐시 두 겹과 '분 단위 99.99% 동일'이라는 문장, 그리고 그 0.01%를 누가 어떻게 세는가
  28. 28 LINE 「LINE에서 Kafka를 사용하는 방법 - 1편」 리뷰 — 초당 4GB 클러스터가 바이트가 아니라 요청 수를 제한하는 이유, 그리고 2,000틱짜리 파이프라인에서 같은 것을 본 기록
  29. 29 카카오 「MySQL 인증 플러그인 caching_sha2_password에 대한 이해」 리뷰 — 비밀번호 해시가 바뀌는 것보다 '평문이 서버까지 가야 한다'는 점이 전환의 진짜 비용
  30. 30 LINE 「초당 100만 건, LINE 앱에 Apache Kafka 종단 간 암호화 적용기」 리뷰 — 인터셉터와 시리얼라이저만으로 브로커에 평문을 남기지 않는 법
  31. 31 카카오뱅크 「하루 N억 건의 알림 시스템 구축기 (1)」 리뷰 — P99의 80%가 대기였다는 진단, Age 기반 Work-Stealing, 그리고 큐를 나누는 순간 순서를 잃는 문제
TechBlog, Kakao
Tech Blog Review Kakao MySQL InnoDB Redo Log WAL Mini Transaction Database Internals
이 기사는 저작권자의 CC BY 4.0 라이센스를 따릅니다.

댓글

아직 댓글이 없습니다