MySQL 26.7: 캘린더 버전 출시·Thread Pool 오픈소스화·포스트 양자 암호화·Change Stream Applier

요약

2026년 7월 28일, Oracle은 MySQL 26.7.0을 GA로 출시했다. 이 릴리스는 여러 이유에서 MySQL 역사에서 전환점이다.

첫째, MySQL 9.7 LTS 시리즈 이후 처음으로 캘린더 버전 체계(Calendar Versioning)를 도입했다. 기존 의미론적 버전(9.x)을 대신해 YY.M.P 형식, 즉 26.7.0처럼 출시 연도·월·패치 번호로 버전을 표현한다. 다음 Innovation 릴리스는 26.10.0이 된다.

둘째, Thread Pool 플러그인이 처음으로 Community Edition에 포함됐다. 기존에는 MySQL Enterprise Edition 전용이었다.

셋째, 새로운 병렬 복제 구현체 Change Stream Applier가 추가됐다. 기존 Multi-Threaded Applier와 채널 단위로 선택적으로 교체할 수 있다.

넷째, OpenSSL 3.5 기반 포스트 양자 암호화(Post-Quantum Cryptography) 지원이 추가됐다.

다섯째, Group Replication의 기본 통신 스택이 XCOM에서 MYSQL로 바뀌었다.

캘린더 버전 체계: 릴리스 리듬의 새 기준

변경 배경

MySQL은 그동안 의미론적 버전(SemVer에 근사한 형식)을 썼다. 8.0 LTS, 8.4 LTS, 9.7 LTS처럼 LTS 시리즈는 2–3년 지원 사이클로 운영하고, Innovation 릴리스는 분기마다 기능 실험을 담았다.

문제는 버전 번호가 언제 릴리스됐는지, 얼마나 오래된 버전인지를 직관적으로 알려주지 못한다는 점이었다.

새 형식: YY.M.P

26.7.0은 2026년 7월에 출시된 첫 번째 패치라는 뜻이다.

캘린더 버전 체계는 Innovation 릴리스에만 적용된다. LTS 시리즈(8.4, 9.7)는 기존 의미론적 버전을 유지한다.

운영 영향

• 버전 비교 스크립트: version >= 9.7처럼 숫자 비교하던 코드는 캘린더 버전(26.7)을 예상치 않아 오작동할 수 있다. 자동화 스크립트와 모니터링 도구에서 버전 파싱 로직을 점검해야 한다.
• 업그레이드 경로: 8.4 LTS → 9.7 LTS → 26.7 Innovation 순서가 지원된다. LTS에서 바로 Innovation으로 업그레이드하려면 사전 테스트가 필요하다.

Thread Pool 플러그인: Community Edition 개방

문제: Connection Storm

기본 MySQL은 one-thread-per-connection 모델이다. 각 커넥션마다 전담 스레드가 하나씩 만들어진다. 커넥션 수가 수백 개를 넘어서면:

• 스레드 스택 메모리가 선형으로 증가한다.
• OS 스케줄러가 과도한 컨텍스트 스위칭 부하를 받는다.
• InnoDB 내부에서 트랜잭션 경합이 증가한다.

Connection Storm(짧은 시간에 커넥션이 폭증하는 현상) 상황에서 이 문제가 두드러진다.

Thread Pool의 해결 방식

Thread Pool 플러그인은 커넥션 수보다 훨씬 적은 고정 크기 워커 스레드 풀을 유지한다. 커넥션이 SQL을 실행할 준비가 됐을 때만 워커 스레드를 배정하고, 결과를 기다리는 동안에는 반납한다.

26.7에서 바뀐 기본값:

활성화 방법

-- my.cnf 또는 my.ini에 추가
[mysqld]
plugin-load-add=thread_pool.so  -- Linux
# plugin-load-add=thread_pool.dll  -- Windows

-- 설정 확인
SHOW VARIABLES LIKE 'thread_pool%';
SHOW STATUS LIKE 'Threadpool%';

Community Edition 사용자는 이제 추가 라이선스 비용 없이 Thread Pool을 활용할 수 있다.

Change Stream Applier: 병렬 복제의 새 구현

기존 Multi-Threaded Applier의 구조

MySQL의 멀티 스레드 복제(Multi-Threaded Applier, MTA)는 코디네이터 스레드가 binlog 이벤트를 워커 스레드에 분배하는 구조다. 분배 단위는 트랜잭션이며, 동일 데이터베이스의 트랜잭션은 직렬화된다(기본 설정 기준).

오래된 아키텍처적 결정이 누적되면서 스케줄링 유연성에 한계가 생겼다.

Change Stream Applier

MySQL 26.7은 채널별로 선택할 수 있는 새 복제 SQL 어플라이어를 도입했다.

-- 채널별로 Change Stream Applier 활성화
CHANGE REPLICATION SOURCE TO
  SOURCE_HOST='primary-host',
  APPLIER_IMPLEMENTATION = 'CHANGE_STREAM';

-- 현재 어플라이어 확인
SELECT CHANNEL_NAME, APPLIER_IMPLEMENTATION
FROM performance_schema.replication_connection_configuration;

Change Stream Applier의 설계 특징:

• 모듈형 스케줄링: 코디네이터와 워커의 결합이 기존보다 느슨하다. 새 스케줄링 정책을 플러그하기 쉬운 구조다.
• 채널 단위 opt-in: 기존 MTA와 공존한다. 채널별로 선택하므로 일부 복제 채널에만 먼저 적용하는 점진적 도입이 가능하다.
• 병렬성 개선 목표: 트랜잭션 병렬 적용 범위 확대가 설계 목표다. 정식 GA 이후 추가 벤치마크가 공개될 예정이다.

Group Replication 기본 통신 스택 변경

26.7부터 Group Replication의 기본 group_replication_communication_stack 값이 XCOM에서 MYSQL로 바뀐다.

MYSQL 스택은 기존 MySQL 서버 TLS 설정과 인증 플러그인을 그대로 활용한다. 방화벽 규칙과 인증서 관리를 별도로 유지할 필요가 없어 운영이 단순해진다.

기존 XCOM 클러스터 업그레이드 주의사항: 이미 XCOM으로 운영 중인 그룹을 26.7로 업그레이드하면 기본값 변경으로 인한 혼선이 생길 수 있다. 업그레이드 전 group_replication_communication_stack=XCOM을 명시적으로 설정하거나, 롤링 업그레이드 시 순서와 설정을 사전에 계획해야 한다.

포스트 양자 암호화 지원

배경

NIST는 2024년 PQC(Post-Quantum Cryptography) 표준을 확정했다. ML-KEM(키 교환), ML-DSA(서명)가 핵심이다. OpenSSL 3.5는 이 표준을 지원하는 첫 번째 OpenSSL 메이저 릴리스다.

MySQL 26.7은 OpenSSL 3.5 이상으로 빌드됐을 때 TLS 1.3 연결에서 PQC 그룹과 서명 알고리즘을 지원한다.

지원 알고리즘

서명 알고리즘 (ML-DSA, CRYSTALS-Dilithium 기반):

키 교환 그룹: 하이브리드 모드(classical + PQC)를 기본으로 권장한다. 기존 클라이언트와의 호환성을 유지하면서 PQC 보호를 추가하는 방식이다.

적용 범위

PQC 지원은 MySQL의 주요 연결 채널 전체에 적용된다.

• 일반 클라이언트 연결
• 관리(admin) 연결
• 복제 연결
• Group Replication 연결
• X Plugin 연결

-- 현재 TLS 설정 확인
SHOW VARIABLES LIKE 'tls_%';
SHOW VARIABLES LIKE 'ssl_%';

-- PQC 그룹 확인 (OpenSSL 3.5+ 빌드 필요)
SHOW VARIABLES LIKE 'tls_ciphersuites';

"장기 보유 데이터(long-lived data)"를 다루는 시스템에서 먼저 평가하는 것이 Oracle의 권고다. 오늘날 암호화된 트래픽을 저장했다가 미래 양자 컴퓨터로 해독하는 "Harvest Now, Decrypt Later" 공격에 대비하는 첫 단계다.

InnoDB 언두 테이블스페이스 트런케이션 개선

기존 방식의 취약점

InnoDB는 트랜잭션 롤백과 MVCC 일관된 읽기를 위해 언두(undo) 로그를 유지한다. 오래된 언두 레코드를 주기적으로 정리하는 과정이 언두 트런케이션이다.

기존에는 트런케이션 진행 상태를 로컬 파일(undo-truncation log file)에 저장했다. 이 파일이 손상되거나 예상치 못한 종료가 발생하면 트런케이션 상태 추적이 어긋나는 경우가 있었다.

26.7의 변경

MySQL 26.7은 트런케이션 진행 상태를 언두 테이블스페이스 헤더에 직접 저장한다.

• 새 트런케이션 로그 파일이 더 이상 생성되지 않는다.
• 기존 트런케이션 로그 파일은 하위 호환성을 위해 계속 인식한다.
• 재시작 후 트런케이션 상태 복구가 더 안정적이다.
• MVCC 가시성과 트랜잭션 동작에는 변화가 없다.

운영 체크리스트: 26.7 업그레이드 전 확인사항

[ ] 버전 파싱 스크립트 점검: "26.7" 형식 대응 여부 확인
[ ] Thread Pool 활용 여부 결정: 고커넥션 워크로드라면 활성화 검토
[ ] Group Replication 통신 스택 명시적 설정: 기존 XCOM 클러스터라면
    group_replication_communication_stack=XCOM 명시 필요
[ ] PQC 요건 확인: 장기 보유 데이터 취급 시 OpenSSL 3.5 빌드 확인
[ ] Change Stream Applier 테스트 환경 평가: 채널별 opt-in 테스트
[ ] MySQL 8.4 LTS / 9.7 LTS 잔존 요건 확인:
    LTS가 필요한 환경은 Innovation 릴리스 업그레이드 불필요

정리

MySQL 26.7은 기능 추가와 함께 운영 모델의 변화를 담았다. 캘린더 버전 체계로 릴리스 타이밍 예측 가능성이 높아졌고, Thread Pool의 Community Edition 개방은 고커넥션 환경에서 유의미한 옵션이 된다.

Change Stream Applier는 병렬 복제 아키텍처를 더 유연하게 만들기 위한 초석이며, PQC 지원은 미래 양자 위협에 대비한 첫 단계다.

Innovation 릴리스이므로 장기 지원이 필요한 프로덕션 환경에서는 LTS(8.4 또는 9.7)를 유지하는 것이 일반적인 권고다. 단, 새 기능을 빠르게 검토하거나 혁신 기능이 필요한 팀에게는 26.7이 첫 번째 캘린더 버전 릴리스로서 충분히 살펴볼 가치가 있다.

References

• Oracle MySQL Blog. "MySQL July 2026 GA Releases Now Available." https://blogs.oracle.com/mysql/mysql-july-2026-ga-releases-now-available
• Oracle MySQL Blog. "A More Predictable MySQL Release Model: Calendar Versions, LTS, and Innovation." https://blogs.oracle.com/mysql/a-more-predictable-mysql-release-model-calendar-versions-lts-and-innovation
• MySQL 26.7 Release Notes. "Changes in MySQL 26.7.0 (2026-07-28)." https://dev.mysql.com/doc/relnotes/mysql/26.7/en/news-26-7-0.html
• Oracle MySQL Blog. "Post-Quantum Cryptography support in MySQL." https://blogs.oracle.com/mysql/post-quantum-cryptography-support-in-mysql
• MySQL 26.7 Reference Manual. "MySQL Releases: Innovation and LTS." https://dev.mysql.com/doc/refman/26.7/en/mysql-releases.html
• VersionLog. "MySQL 26.7 — What's New, Support Lifecycle & EOL." https://versionlog.com/mysql/26.7/