트랜잭션 지원 메타데이터

MySQL 8.0의 큰 변화 중 하나는 메타데이터를 트랜잭션 기반으로 관리하기 시작했다는 점이다. 덕분에 DDL이 훨씬 안전해졌고, 오랫동안 MySQL 운영자를 괴롭히던 "DDL 도중 서버가 죽으면 메타데이터가 깨진다"는 문제가 사라졌다.

5.7 이하에서의 문제

MySQL 5.7까지는 테이블 구조, 트리거, 파티션 정보 같은 메타데이터를 별도의 파일로 관리했다.

• .frm — 테이블 구조
• .trg, .trn — 트리거
• .par — 파티션 정보
• .opt — 데이터베이스 옵션

이 파일들은 단순한 OS 파일이라 트랜잭션 보호를 받지 못했다. 그래서 다음과 같은 상황이 자주 발생했다.

• CREATE TABLE 실행 도중 서버가 비정상 종료
• .frm 파일은 생성되었는데 InnoDB 내부에는 테이블이 없거나, 반대로 InnoDB에는 만들어졌는데 .frm이 없는 상태로 남음
• 그 결과 같은 이름의 테이블을 다시 만들 수도, 지울 수도 없는 메타데이터 불일치 상태가 발생

이 상태가 되면 운영자가 직접 파일을 손으로 정리하거나, 시스템 테이블을 수동으로 건드려야 복구되는 경우가 많았다.

8.0의 해결: 데이터 딕셔너리

MySQL 8.0은 모든 메타데이터를 InnoDB 테이블에 저장하도록 바꿨다. 이 메타데이터 저장소를 데이터 딕셔너리(Data Dictionary)라고 부른다.

메타데이터가 InnoDB 테이블에 들어가면서 다음 특성들을 자연스럽게 얻었다.

• 트랜잭션 보호 — 변경이 ACID로 처리된다
• 크래시 복구 가능 — 리두 로그/언두 로그의 보호를 받는다
• 일관된 격리 수준 — 트랜잭션 내에서 같은 메타데이터 뷰를 본다

그 결과 .frm, .par, .trg, .trn, .opt 같은 파일들은 8.0에서 모두 사라졌다.

Atomic DDL

데이터 딕셔너리가 트랜잭션 기반이 되면서, 8.0은 Atomic DDL 기능을 새로 제공한다. Atomic DDL은 DDL 한 건이 다음 세 가지를 하나의 원자적 단위로 묶어서 처리하는 것을 보장한다.

1. 데이터 딕셔너리 업데이트
2. 스토리지 엔진 작업 (테이블 파일 생성/삭제 등)
3. 바이너리 로그 기록

셋 다 성공하거나, 셋 다 실패한다. 중간에 서버가 죽어도 어느 한쪽만 적용된 상태로 남지 않는다.

다만 모든 DDL이 atomic으로 처리되는 것은 아니다. InnoDB 테이블에 대한 CREATE, DROP, ALTER, RENAME 같은 작업은 atomic이지만, INSTALL PLUGIN 같은 일부 작업은 여전히 atomic이 아니다.

운영에 미치는 영향

• DDL 도중 장애가 발생해도 데이터 딕셔너리가 깨지지 않는다. 장애 복구 절차가 단순해진다.
• 백업/복제 환경에서 메타데이터와 실제 데이터의 일관성이 더 잘 보장된다.
• 과거 .frm 파일을 직접 읽던 외부 도구는 8.0에서 동작하지 않을 수 있다. 도구를 같이 점검해야 한다.