포스트

카카오 「MySQL Ver. 8.0 New Feature: Instant DDL Algorithm에 대한 이해」 리뷰 — 컬럼을 0.01초에 추가하는 대가는 '읽을 때마다 버전을 대조하는 것'이다

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

원문: MySQL Ver. 8.0 New Feature: Instant DDL Algorithm에 대한 이해 — kakao tech, 2025-09-02 (2023-11 분석, 8.0.29 기준)

한 줄 요약

8.0.12의 Instant v1은 컬럼을 마지막에 추가만 됐고, 8.0.29의 v2는 어느 위치든 추가·삭제가 된다. 비결은 데이터 파일을 건드리지 않고 메타데이터만 바꾸는 것이다. 테이블에는 Instant DDL을 몇 번 했는지(ROW_VERSION, 최대 64)와 컬럼마다 언제 추가·삭제됐는지(VERSION_ADDED/VERSION_DROPPED)를 적고, 각 행 헤더에는 그 행이 쓰일 당시의 ROW_VERSION을 적는다. 읽을 때는 행의 버전과 컬럼의 버전을 비교해 “이 컬럼은 이 행에 실제로 있는가, 없으면 기본값”을 결정한다. 원문은 xxd로 데이터 파일을 열어 삭제한 컬럼 값이 그대로 남아 있고 추가한 컬럼 값은 없음을 직접 확인한다. Fetch가 복잡해지니 SELECT가 느려질 수 있는데, 카카오 표준 구성에서 sysbench로 재 보니 의미 있는 저하는 없었다.

배경: Copy → In-Place → Instant

Copy는 DDL 내내 읽기 락을 잡고 임시 테이블로 데이터를 옮겨 24시간 서비스에서는 중단이 필요했다. In-Place는 긴 락은 없앴지만 “새 테이블을 만들고 복사한다”는 본질은 같아 테이블이 클수록 공간과 시간이 든다. Instant는 그 본질을 바꿔 물리 구조를 안 건드린다. 1.6GB 테이블에 0.01초 만에 컬럼이 추가된다.

v1의 한계와 v2의 ROW_VERSION

v1(8.0.12)은 마지막 컬럼으로만 추가할 수 있고 DROP은 안 됐다. v2(8.0.29)는 내부 설계를 바꿔 위치 무관 추가·삭제를 지원한다. 핵심 개념이 ROW_VERSION이다. 테이블마다 독립적으로 Instant DDL이 수행된 횟수이고, 테이블 메타데이터와 행 메타데이터 두 곳에 각각 저장된다.

  • INFORMATION_SCHEMA.INNODB_TABLES.TOTAL_ROW_VERSIONS로 확인한다. 생성 시 0, Instant 추가 후 1, Instant 삭제 후 2.
  • 64가 상한이다. 넘으면 “Maximum row versions” 오류. 더 중요한 점: 64에 닿은 뒤 ALGORITHM=INSTANT를 명시하지 않고 DDL을 돌리면 조용히 In-Place로 동작한다. 의도치 않은 긴 작업이 될 수 있다.
  • 초기화는 테이블 재구축이다(TRUNCATE도 되지만 데이터가 사라지니 의미 없음).
  • 여전히 FULLTEXT 인덱스가 있는 테이블, ROW_FORMAT=COMPRESSED, 임시 테이블에서는 못 쓴다.

메타데이터와 물리 구조의 불일치를 어떻게 메우는가

Instant로 컬럼을 추가해도 데이터 파일의 행에는 그 컬럼이 없고, 삭제해도 행에는 값이 남아 있다. 이 불일치를 메우는 정보가 세 가지다.

행 메타데이터. 행 헤더의 INFO BITS(4비트) 중 두 번째 비트가 “이 행에 ROW_VERSION이 있는가”다. 있으면 행이 삽입·수정될 때의 테이블 TOTAL_ROW_VERSIONS 값이 기록된다.

테이블 메타데이터. 컬럼마다 VERSION_ADDED(어느 버전에 추가됐나)와 VERSION_DROPPED(어느 버전에 삭제됐나). ROW_VERSION 0인 테이블에서 C1을 삭제하면 ROW_VERSION=1, C1의 VERSION_DROPPED=1. 이어 C2를 추가하면 ROW_VERSION=2, C2의 VERSION_ADDED=2. 이 값들은 Data Dictionary에 있다고 문서에 있지만 물리 위치는 파악하지 못했다고 원문이 솔직히 적는다.

Fetch 규칙.

  1. VERSION_ADDED와 VERSION_DROPPED가 모두 0인 컬럼은 파일 값을 그대로 쓴다.
  2. VERSION_DROPPED가 0이 아닌 컬럼은 결과에서 제외한다.
  3. VERSION_ADDED가 0이 아닌 컬럼은 행의 ROW_VERSION과 비교한다. 컬럼의 VERSION_ADDED가 행의 ROW_VERSION보다 크면(행이 쓰일 때 그 컬럼이 없었음) 기본값을 읽고, 작으면(행이 쓰일 때 이미 있었음) 파일 값을 읽는다.

직접 확인한 시나리오

테이블 [c1, c2, c3, c4] 생성 → 행 R1 삽입(ROW_VERSION 0) → c5 추가 → c3 삭제 → R1 조회.

xxd로 데이터 파일을 보면, c5 추가 후 SELECT에는 기본값 ‘rE’가 나오지만 파일에는 그 값이 없다. c3 삭제 후 SELECT에는 c3이 없지만 파일에는 ‘rC’가 남아 있다. 단계별로 행을 추가하며 보면 첫 행은 INFO BITS 두 번째 비트가 0이고 ROW_VERSION이 없다. 컬럼 추가 후 삽입한 행은 ROW_VERSION 1, INFO BITS가 4(두 번째 비트 1). 삭제 후 삽입한 행은 ROW_VERSION 2.

UPDATE는 어떻게 되나

Instant DDL을 3번 한 테이블(TOTAL_ROW_VERSIONS=3)에서 ROW_VERSION 1인 행을 UPDATE하면 두 경우로 갈린다.

  • 작아지는 갱신(c2를 ‘r2B’ → ‘rU’): 제자리에서 바뀌고 ROW_VERSION이 1 → 3으로 갱신된다.
  • 커지는 갱신(c2를 ‘rBRBRBR…’): 제자리에 못 들어가 페이지 뒤쪽에 새로 쓰이고 ROW_VERSION 3이 붙는다. 기존 행은 그대로 남는다.

즉 행은 갱신될 때 현재 테이블 버전으로 “승격”되고, 그 시점에 물리 구조가 현재 컬럼 구성으로 다시 쓰인다.

성능 우려와 실측

Fetch가 컬럼마다 버전 비교를 하므로 SELECT가 느려질 수 있다. 카카오는 이를 인지하고 sysbench의 bulk_insert, oltp_read_write 시나리오로 Instant DDL 후 성능을 쟀고, 표준 DB 구성에서는 의미 있는 저하가 없다고 판단했다. 원문의 결론은 신중하다. 서비스 영향은 낮아졌지만 SELECT 저하가 예측되니 쓰는 것이 맞는지 고민하고, 특징과 제한을 알고 필요한 곳에 쓰라는 것이다.

읽고 남는 질문

  • sysbench 결과의 수치가 없다. “의미 있게 저하되지 않는다”의 크기(예: 1% 이내)와 ROW_VERSION이 64 근처일 때(컬럼 버전 비교가 가장 많을 때)의 결과가 있으면 훨씬 설득력이 있다.
  • 삭제한 컬럼 값이 파일에 남아 있다는 것은 디스크 공간이 회수되지 않는다는 뜻이다. 큰 컬럼을 Instant DROP한 뒤 공간을 되찾으려면 결국 재구축이 필요한데, 그 운영 가이드가 있으면 좋겠다.
  • 64에 닿았을 때 명시 없이 In-Place로 떨어지는 동작은 앞선 ALTER DDL 글의 “ALGORITHM을 명시하라”와 정확히 연결된다. 두 글을 함께 읽으면 그 조언의 무게가 달라진다.

한 줄로 가져가기

Instant DDL은 “지금 바꾸는 것”을 “읽을 때 해석하는 것”으로 미룬 기술이다. 그래서 빠르고, 그래서 행마다 버전이 붙고, 그래서 64번이 지나면 미룬 것을 한꺼번에 갚아야 한다.

시리즈

빅테크 기술 블로그 리뷰

31편 중 7편

이전 시리즈 글 카카오 「MySQL Orchestrator 기반의 새로운 HA 표준 개발기」 리뷰 — 10년 멈춘 Perl 도구를 떠나 Raft 클러스터로, 그리고 slave_net_timeout 한 줄 다음 시리즈 글 네이버 D2 「CDC 복제 이후 오라클이 느려졌다? child cursor 폭증이 만든 예상치 못한 문제」 리뷰 — 같은 SQL인데 바인딩 타입이 다르면 Oracle은 다른 쿼리로 본다
  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 Instant DDL Online DDL Database Internals Row Format
이 기사는 저작권자의 CC BY 4.0 라이센스를 따릅니다.

댓글

아직 댓글이 없습니다