MySQL 8.0 → 8.4 LTS 업그레이드
장비별 쓰기 성능을 먼저 비교하고 설정을 조정한 뒤 인스턴스별 순서에 따라 버전을 올렸습니다.
작업 요약
MySQL 8.0 → 8.4 LTS · 당시 고객사 8곳 반영
서버별로 검증하며 버전을 올렸습니다
이 업그레이드에서 실제로 검증한 것은 연결된 복제 체인, 고객사 on-premise 영향, 성능 변화였습니다. 운영에 미치는 영향을 확인하려면 적용 순서와 단계별 확인 항목을 먼저 정해야 했습니다.
8.4 LTS 전환 과정에서 인스턴스별로 검증하고 고객사 영향 범위를 나눈 이유는, 문제가 생겼을 때 되돌릴 단위를 작게 만들기 위해서였습니다.
배경
제품 데이터 백엔드는 primary와 replica, 고객사 on-premise가 연결된 복제 환경으로 운영됩니다. 당시 운영 버전은 8.0.29로, 지원 종료(EOL)가 다가와 차기 LTS인 8.4.0 LTS로 올려 보안 패치 수명과 운영 기능을 확보해야 했습니다.
- MySQL 8.0 bugfix series의 8.0.29에서 8.4.0 LTS로 올리는 변경이라, 제거된 기능과 동작 변경에 대한 호환성 검증이 필요했습니다.
- 중앙 운영 환경뿐 아니라 고객사 on-premise까지 영향이 가므로 적용 순서와 롤백 절차를 먼저 정리했습니다.
- 적용 범위 — 수집 DB 1대, 배포 DB 2대, 고객사용 master DB와 수집·배포 인스턴스별 레플리카 각 2대, 그리고 당시 고객사 8곳의 on-premise 환경까지 반영
접근
- 검증
성능·호환성 테스트 환경에서 8.4 벤치마크
- 계획
변경 영향과 롤백 절차 정리
- 롤아웃
백업 후 서버별로 적용 범위를 확대
- 확인
복제 상태와 고객사 동기화 확인
검증계에서 호환성과 성능을 먼저 확인하고 백업을 남겼습니다. 운영 적용은 서버별로 나눴고, 각 단계에서 복제 상태와 오류 로그를 확인한 뒤 다음 서버로 넘어갔습니다. 서버별 적용 순서 세부는 이 페이지에서는 생략합니다.
결과
역할
성능 검증과 롤아웃 계획을 작성하고 프로덕션 적용 뒤 안정화까지 맡았습니다. 적용 순서는 팀장·CTO와 협의했으며, 중앙 운영 환경과 고객사 on-premise의 버전 차이를 반영해 서버별 변경 영향과 롤백 절차를 미리 정했습니다.
같은 해 진행한 바이너리 로그 암호화, DB 아키텍처 인스턴스 분리는 별도 항목으로 정리.