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