76편 · 약 15분

MySQL 26.7: 캘린더 버전 관리 전환과 Change Stream Applier·Thread Pool 오픈소스화로 달라진 운영 기준

MySQL 버전 번호가 바뀐 이유

MySQL 9.7 LTS가 2026년 4월 출시된 지 세 달이 지났다. 그리고 2026년 7월, Oracle은 새 버전 번호를 들고 왔다. MySQL 26.7.0이다.

9.7 다음에 26.7? 번호 규칙이 바뀐 것이다.

Oracle은 MySQL Innovation 릴리스 계열에 캘린더 버전 관리(Calendar Versioning, CalVer)를 도입했다. 포맷은 YY.M.P — 두 자리 연도, 월, 패치 번호다. 2026년 7월 첫 번째 릴리스이므로 26.7.0이다. 다음 Innovation 릴리스는 2026년 10월에 MySQL 26.10.0으로 나올 예정이다.

이 변화의 배경을 이해하면 MySQL 릴리스 추적 방식도 달라진다.

MySQL 릴리스 트랙: LTS vs Innovation

MySQL은 두 가지 릴리스 트랙을 유지한다.

MySQL 릴리스 트랙 구조 — LTS와 Innovation 계열

LTS 트랙은 안정성 중심이다. MySQL 9.7 LTS는 장기 지원 버전으로, 최소 5년간 분기별 보안·버그 픽스를 받는다. 온프레미스 운영 환경, 규제 산업, 잦은 업그레이드가 어려운 환경에 적합하다.

Innovation 트랙은 최신 기능을 분기마다 제공한다. 개발 환경, 테스트 가능한 운영 환경, 새 기능을 빠르게 검토하려는 팀에 적합하다. 기존 버전인 MySQL 9.x Innovation도 동일한 역할을 했으나, CalVer로 전환하면서 릴리스 일정을 번호에서 직접 읽을 수 있게 됐다.

CalVer의 운영적 의미: 버전 번호만 보고 "언제 나왔는지"를 즉각 파악할 수 있다. 26.7 = 2026년 7월, 26.10 = 2026년 10월. 더 이상 릴리스 날짜를 별도 문서에서 확인할 필요가 없다.

Change Stream Applier: 복제 병렬화의 새로운 엔진

MySQL 26.7의 가장 주목할 기능은 Change Stream Applier(CSA)다.

기존 MTA의 한계

복제 레플리카(replica)가 바이너리 로그를 적용하는 방식은 오랫동안 두 가지였다.

단일 스레드 모드(STS): 트랜잭션을 하나씩 직렬 처리. 가장 간단하지만 소스 서버 쓰기 속도를 따라가지 못할 수 있다.
멀티스레드 어플라이어(MTA): 여러 워커 스레드가 병렬로 트랜잭션을 적용한다. 단, 같은 데이터베이스나 테이블에 쓰는 트랜잭션은 의존성 때문에 직렬화되어 병렬 처리 효율이 제한적이다.

MTA는 replica_parallel_workers 파라미터 하나로 전체 복제 채널에 적용하는 전역 설정이다. 여러 채널이 있어도 하나의 설정값을 공유한다.

CSA 설계: 채널별 독립 설정

CSA는 채널별로 독립적인 어플라이어를 구성한다. 새 파라미터 APPLIER_VERSION=2를 지정한 채널에서만 CSA가 동작한다. 기존 MTA와 CSA가 서버 내에서 채널별로 공존한다.

-- CSA 활성화 예시 (채널별 opt-in)
CHANGE REPLICATION SOURCE TO
  SOURCE_HOST = 'source.example.com',
  SOURCE_USER = 'repl',
  SOURCE_PORT = 3306,
  APPLIER_VERSION = 2,
  APPLIER_THREAD_COUNT = 16
FOR CHANNEL 'primary-dc';

APPLIER_THREAD_COUNT는 채널당 1~1024개로 설정 가능하다. MTA의 전역 replica_parallel_workers와 달리 채널마다 다른 워커 수를 배정할 수 있다.

기존 MTA

replica_parallel_workers = 8

→ 채널 A: 8 워커 공유

→ 채널 B: 8 워커 공유

→ 모든 채널 동일 설정

CSA (APPLIER_VERSION=2)

채널 A: APPLIER_THREAD_COUNT=16

채널 B: APPLIER_THREAD_COUNT=4

→ 채널별 독립 설정, 1~1024

CSA 장점: 쓰기 부하가 다른 여러 소스를 각각 최적화 가능. 중요 채널에 더 많은 워커 배정.

MTA와 CSA 비교 — 스레드 관리 모델 차이

Oracle은 CSA를 모듈형 스케줄링·실행 모델로 설계해 향후 복제 개선의 기반으로 사용할 계획임을 명시했다. MTA를 직접 교체하는 것이 아니라 채널별 opt-in 방식으로 단계적 전환을 지원한다.

현재 상태: MySQL 26.7.0 기준 CSA는 실험적(experimental) 기능이다. 프로덕션 적용 전 충분한 테스트가 필요하다.

Thread Pool Plugin: 커뮤니티 에디션 개방

MySQL에서 동시 접속이 늘어나면 기본 one-thread-per-connection 모델이 병목이 된다. 접속 하나마다 OS 스레드 하나가 생성되므로, 수천 개의 동시 연결은 컨텍스트 스위칭 오버헤드와 스케줄러 부담을 높인다.

Thread Pool Plugin은 고정된 수의 워커 스레드 풀을 유지한다. 다수의 접속이 풀에서 스레드를 빌려 실행된다. 접속 수가 스레드 수를 초과해도 스레드 수는 제한적으로 유지된다.

지금까지 이 플러그인은 MySQL Enterprise Edition 전용이었다. MySQL 26.7.0부터 Community Edition에서도 사용 가능해졌다. Oracle은 이 결정을 "더 많은 사용자가 Thread Pool 스케줄링을 평가하고 사용할 수 있도록"이라고 설명했다.

언제 Thread Pool이 도움이 되는가?

수백~수천 개의 동시 접속이 있는 OLTP 환경
각 쿼리가 짧고 빠르며 접속이 자주 열리고 닫히는 패턴
CPU 코어 수 대비 접속 수가 과도한 경우

주의사항: Thread Pool은 모든 워크로드에 만능이 아니다. 장시간 실행되는 쿼리가 혼재하거나, 접속 수가 적은 환경에서는 오히려 복잡성만 늘어날 수 있다. 도입 전 벤치마킹이 필수다.

기타 개선사항

InnoDB undo log 자동 절단 강화

MySQL은 오래된 언두(undo) 로그를 자동으로 절단(truncation)하는 기능을 갖고 있다. 26.7.0에서는 이 절단 과정의 안정성이 향상됐다. 오랫동안 실행되는 트랜잭션이 언두 로그 공간을 비정상적으로 점유하는 경우의 처리가 개선됐다. 대규모 트랜잭션이나 배치 작업을 실행하는 환경에서 언두 로그 공간 관리가 좀 더 예측 가능해진다.

업그레이드 성능 개선

MySQL 버전 업그레이드 시 mysql.general_log와 mysql.slow_log 테이블에 대한 ALTER TABLE 구문이 내부적으로 실행된다. 26.7.0에서는 이 구문이 간소화되어 업그레이드 소요 시간이 줄어들었다. 대용량 로그 테이블을 보유한 환경에서 체감 효과가 있다.

DBA를 위한 운영 체크리스트

LTS vs Innovation 선택 기준

상황	권장 트랙
프로덕션 OLTP, 규제 환경	LTS (MySQL 9.7)
개발·QA 환경, 새 기능 검토	Innovation (MySQL 26.7)
업그레이드 주기가 길어야 하는 경우	LTS
분기마다 업그레이드 가능한 조직	Innovation

MySQL 26.7 도입 시 검토 사항

기존 MTA 설정 유지: CSA는 opt-in이다. APPLIER_VERSION을 지정하지 않은 채널은 기존 MTA로 그대로 동작한다. 현재 복제 설정을 바꿀 필요 없다.

Thread Pool 테스트 환경 구성: 커뮤니티에서 처음 사용 가능해진 기능이다. 프로덕션 적용 전 반드시 스테이징 환경에서 접속 패턴별 성능을 측정한다.

버전 번호 추적 도구 업데이트: 모니터링 시스템, 버전 비교 스크립트에서 MySQL 버전을 비교할 때 9.7 형식과 26.7 형식이 섞이지 않도록 주의한다. SHOW VARIABLES LIKE 'version' 결과를 파싱하는 로직을 점검한다.

CSA는 실험적 기능: APPLIER_VERSION=2는 실험 단계다. 복제 지연, 데이터 일관성 검증을 강화한 후 프로덕션에 적용한다.

한계와 Open Question

CSA의 실제 성능 향상 폭: Oracle은 CSA의 모듈형 설계가 병렬 트랜잭션 적용을 개선한다고 설명하지만, 구체적인 벤치마크는 공식적으로 공개되지 않았다. 실제 워크로드에서 MTA 대비 얼마나 빠른지는 직접 측정이 필요하다. (Open question)

Thread Pool과 준비된 구문(Prepared Statements): Thread Pool을 사용하면 준비된 구문의 세션 바인딩 방식에 주의가 필요하다는 기존 MySQL 주의사항이 여전히 적용된다. 애플리케이션이 Prepared Statement를 많이 사용한다면 Thread Pool 이전에 동작을 검증해야 한다.

CalVer와 하위 호환성 정책: Innovation 릴리스 간 하위 호환성 보장 범위가 LTS보다 느슨하다. 26.7 → 26.10 업그레이드 시 어떤 변경이 있을지는 26.10 릴리스 노트 공개 전에는 알 수 없다.

장기적 Innovation 지원 정책: LTS와 달리 Innovation 릴리스의 지원 기간은 짧다. 다음 Innovation 릴리스가 나오면 이전 버전의 지원이 사실상 종료된다. 분기별 업그레이드가 운영 부담이 되는 팀에게는 LTS가 더 현실적이다.

정리

MySQL 26.7.0은 단순한 마이너 릴리스가 아니다.

캘린더 버전 관리 전환은 Oracle이 MySQL의 릴리스 예측 가능성을 높이겠다는 장기 전략의 표현이다. 버전 번호에서 릴리스 시점을 직접 읽을 수 있게 됐다.

Change Stream Applier는 10년 이상 MySQL 복제 레이어에서 유지되던 MTA 구조를 처음으로 대안 설계로 교체하는 시도다. 채널별 독립 설정(1~1024 워커)과 모듈형 스케줄러는 향후 복제 개선의 기반이 될 예정이다.

Thread Pool Plugin의 커뮤니티 개방은 엔터프라이즈 전용이던 기능이 오픈소스로 내려온 사례로, 고동시 접속 환경의 MySQL 운영에 새로운 선택지를 제공한다.

이 세 가지 변화는 각각 독립적으로 중요하다. DBA로서는 LTS vs Innovation 트랙 전략을 다시 정의하고, CSA와 Thread Pool을 테스트 환경에서 미리 평가하는 것이 2026년 MySQL 운영의 다음 행동 항목이 된다.