MySQL 8.0 EOL 대비: 8.4 LTS와 9.x 마이그레이션 판단

8.0 지원 종료가 남기는 운영 과제

Oracle 공식 릴리스 노트 기준으로 MySQL 8.0은 2026년 4월 EOL(End of Life)에 이르며, 8.0.46이 최종 패치 버전이다. 이후에는 보안 패치, 버그 수정, 기술 지원이 중단된다. 프로덕션 트래픽을 운영한다면 8.4 LTS 또는 9.x Innovation 중 어느 경로로 이동할지 정하고, 인증·스키마·복제 설정의 호환성을 먼저 확인해야 한다.

지원이 끝난 소프트웨어는 CVE 대응 패치와 신규 기능 백포트를 받을 수 없다. PCI-DSS, HIPAA, SOC2 등의 보안 요구사항에서 미지원 소프트웨어 사용이 문제가 될 수도 있다.

지원 종료 시점은 다음과 같다.

MySQL 8.0 Premier Support 종료: 2025년 4월
MySQL 8.0 Extended Support 종료: 2026년 4월
최종 패치: 8.0.46

지원 주기가 다른 8.4 LTS와 9.x

⤢✕

8.4 LTS는 Premier Support 5년과 Extended Support 3년으로 총 8년을 지원한다. 기능은 동결되고 버그·보안 패치만 백포트되므로, 프로덕션 엔터프라이즈 워크로드에 맞는 모델이다. Extended Support까지 포함하면 약 2032년 4월까지 지원 기간을 확보할 수 있다.

Innovation Release는 약 90일 단위로 새 릴리스가 나오며, 다음 Innovation 또는 다음 LTS 출시까지만 지원된다. 신기능 검증이나 SaaS 내부 플랫폼처럼 빠른 업데이트를 감당할 수 있는 환경에 적합하다.

항목	MySQL 8.4 LTS	MySQL 9.x Innovation
지원 주기	Premier 5년 + Extended 3년	다음 릴리스까지(~90일)
대표 신기능	자동 히스토그램, 복제 강화	VECTOR 타입, JavaScript 저장 프로시저
안정성	높음(기능 동결)	낮음(실험적 기능 다수)
업그레이드 빈도	5년 주기	분기별
프로덕션 권장	권장	조건부(검증 필수)
벡터 검색	미지원	pgvector 유사 VECTOR 지원

안정성을 우선하는 조직은 8.0에서 8.4 LTS로 이동하는 편이 맞다. VECTOR 타입이나 JavaScript 저장 프로시저처럼 최신 기능이 반드시 필요하고 분기 업그레이드를 운영 체계에 포함할 수 있다면 9.x Innovation도 선택지가 된다.

8.4에서 확인할 변경 지점

8.4 LTS에는 AUTO_UPDATE 옵션을 활용한 자동 히스토그램 업데이트가 포함되어 통계 최신화와 옵티마이저 정확도 향상을 지원한다. InnoDB Purge 스레드는 vCPU를 기준으로 innodb_purge_threads를 자동 조정한다.

그룹 복제에서는 노드 장애 복구 속도와 XCom 프로토콜이 개선되었고, 복제 프레임워크는 CHANGE REPLICATION SOURCE TO 문법을 중심으로 정리됐다. JOIN 순서와 인덱스를 강제하는 옵티마이저 힌트도 확장됐다. 기본 인증 플러그인은 caching_sha2_password로 완전히 전환된다.

마이그레이션에서 더 민감한 부분은 기능 추가보다 기존 동작과의 충돌이다.

mysql_native_password는 8.4부터 기본 비활성이고 9.0에서는 완전히 제거된다. 구버전 클라이언트 드라이버는 즉시 접속에 실패할 수 있으므로 caching_sha2_password로 사용자를 재생성하거나 클라이언트를 업그레이드해야 한다.
외래 키가 참조하는 부모 테이블 컬럼에는 UNIQUE 키가 필요하다. 기존 관대 모드에서 만들어진 스키마는 보정이 필요하다.
FLUSH HOSTS는 TRUNCATE TABLE performance_schema.host_cache로 대체된다. 구형 암호화 함수와 해시 함수 일부가 제거되고, 레거시 utf8(=utf8mb3) 기본값에는 경고가 발생한다.
binlog_transaction_dependency_tracking, replica_preserve_commit_order 등 복제 관련 기본값이 조정된다. innodb_change_buffering은 기본 비활성화되므로 쓰기 성능을 다시 평가해야 한다.

워크로드에서 시작하는 대상 버전 선택

⤢✕

대규모 OLTP처럼 안정성이 우선인 경우에는 8.4 LTS를 기준으로 잡는다. 실험 환경이나 SaaS 내부 플랫폼에서 신기능이 필수라면 9.x Innovation을 검토할 수 있다. 어느 쪽을 고르더라도 호환성 체커 실행, 이슈 수정, 스테이징 검증, 롤링 업그레이드 순서는 유지된다.

Replica부터 교체하는 롤링 업그레이드

롤링 업그레이드는 Source(Primary) 1대와 Replica(Secondary) N대로 구성된 복제 토폴로지를 전제로 한다. 비동기 복제, 반동기 복제, 그룹 복제에 적용할 수 있다.

서비스 트래픽에서 제외한 Replica부터 순차적으로 업그레이드한다. 모든 Replica 전환이 끝나면 Primary를 장애 조치(failover)하고, 기존 Primary를 최신 버전으로 업그레이드한 뒤 Replica로 다시 편입한다.

ProxySQL이나 HAProxy를 사용하면 전환 중 라우팅을 제어할 수 있다. 읽기 트래픽은 업그레이드된 Replica로 분산하고, 쓰기 트래픽은 failover 시 수 초 내 전환한다.

롤백은 업그레이드 전에 준비해야 한다. XtraBackup 물리 백업과 mysqldump 논리 백업을 함께 확보하고, 바이너리 로그 기반 PITR을 준비한다. 복제 GTID 정합성을 확인하는 스크립트도 상시 실행한다.

호환성과 성능을 함께 검증하기

MySQL Shell의 util.checkForServerUpgrade()로 제거된 예약어, 비호환 자료형, 인증 플러그인, 스토리지 엔진, SQL 모드를 자동 진단한다. 이 결과만으로 전환 판단을 끝내기보다 애플리케이션과 운영 환경의 검증으로 이어가야 한다.

통합 테스트 스위트는 8.4와 9.x 컨테이너 각각에 실행한다. MyBatis, Hibernate, SQLAlchemy 같은 ORM의 드라이버 버전 매트릭스를 확인하고, HikariCP 등의 커넥션 풀에서 타임아웃과 SSL 설정을 재검토한다.

성능 회귀는 sysbench·TPC-C로 TPS와 지연을 비교하고, EXPLAIN 실행계획과 인덱스 선택 변화를 추적한다. Slow Query Log도 업그레이드 전후로 diff한다. 보안 검증에서는 암호화 알고리즘 호환성, TLS 1.3 강제화, 사용자 권한과 역할(Role) 이관을 확인한다.

전환 전에 확인할 항목

MySQL 8.0.22 이상으로 선제 업그레이드(직접 8.4 업그레이드 전제)
mysql_native_password 사용자 전수 조사 및 재생성
외래 키 제약·UNIQUE 인덱스 정합성 검증
SQL 모드 차이(ONLY_FULL_GROUP_BY 등) 영향 분석
복제 GTID·바이너리 로그 형식(ROW) 확인
애플리케이션 드라이버·ORM·커넥션 풀 버전 매트릭스 확정
스테이징 환경에서 실데이터 샘플 기반 부하 테스트 수행
롤백 시나리오 문서화 및 리허설
모니터링 대시보드(Prometheus·Percona PMM) 메트릭 기준선 재수립

다른 이전 경로를 검토할 때

Amazon RDS for MySQL 8.4 LTS는 관리형 서비스로 패치를 자동화하고 vCPU 기반 Purge 스레드 자동 스케일을 제공한다. Percona Server for MySQL 8.4는 XtraDB·TokuDB 확장 기능을 제공하는 오픈소스 대안이다.

플랫폼 자체를 바꾸는 선택지도 있다. MariaDB 11.x는 포크 계열로 JSON·시스템 버전 테이블 같은 차별 기능을 제공한다. PostgreSQL 17은 JSON·파티셔닝·복제 성숙도를 기반으로 장기적 전환 후보가 될 수 있다. Aurora MySQL Compatible은 8.4 호환 릴리스를 통한 단계적 이전 경로를 제공한다.

MySQL 8.0 EOL 대응은 단순한 버전 교체가 아니다. 인증 플러그인, 외래 키 제약, 복제 기본값처럼 기존 환경에 영향을 주는 변경을 확인해야 한다. 8.4 LTS는 2032년 4월까지의 장기 지원을 확보하는 경로이며, 9.x Innovation은 벡터 검색과 JavaScript 저장 프로시저가 필요한 환경에서 분기 업그레이드 리듬을 전제로 선택할 수 있다.