Cloud SQL MySQL blue-green 프리뷰: READY와 롤백을 혼동하지 않기

운영 DB와 검증용 DB 사이의 계획된 전환을 표현한 생성형 개념 이미지다. 실제 Google Cloud 화면이 아니다.

MySQL 업그레이드 때 운영 중단을 줄이고 싶다면, 새 버전을 별도 환경에서 검증한 뒤 연결 대상을 바꾸는 방법이 유용하다. Cloud SQL의 새 blue-green 프리뷰는 이 과정을 관리하지만, 전환 준비 상태가 테스트 합격을 뜻하거나 이전 DB 보존이 자동 롤백을 보장하지는 않는다.

Google은 2026년 10월 28일 Cloud SQL for MySQL의 관리형 blue-green 배포 프리뷰를 발표했다. 운영 환경을 유지하며 업그레이드된 복사본을 검증하는 것이 핵심이다. 정식 출시로 오해하지 말고, 실제 도입 전 프리뷰 지원 조건을 확인해야 한다. 공식 발표

먼저 지원 범위부터 좁힌다

공식 문서상 메이저 업그레이드는 MySQL 8.0에서 8.4로 가는 경로를 지원한다. 같은 버전에서 구성 변경을 준비하는 경우는 MySQL 5.7 이상이 대상이지만, 8.0.18은 제외된다. PostgreSQL·SQL Server나 읽기 복제본이 붙은 인스턴스에 그대로 적용하는 기능이 아니다.

새 네트워크 아키텍처, 자동 백업과 바이너리 로그, 최신 유지보수 버전도 확인한다. PSC outbound 구성과 MySQL IAM 그룹 인증에는 제한이 있다. HA 구성 지원 여부와 읽기 복제본 지원 여부는 서로 다른 조건이다. 지원 범위와 제한

동작 원리: 복사본에서 검증하고, 연결 지점을 바꾼다

기존 운영 DB가 blue, 변경을 준비하는 복사본이 green이다. 검증 단계에서는 blue에서 green으로 논리 복제가 이어진다. 전환하면 green이 운영 읽기·쓰기를 맡고 연결 지점이 교체된다.

공식 전환 문서는 짧은 연결 중단이 발생한다고 설명한다. “연결 문자열을 바꾸지 않아도 된다”와 “진행 중인 요청이 한 번도 실패하지 않는다”는 같은 말이 아니다. 애플리케이션의 연결 풀 재접속과 실패한 트랜잭션 처리도 검증해야 한다. 전환 동작

READY는 애플리케이션 합격 판정이 아니다

SWITCHOVER_READY는 전환 절차가 가능한 상태이지, 쿼리 호환성이나 서비스 SLO를 검사한 결과가 아니다. 특히 이 상태를 정할 때 복제 지연까지 평가하지 않는다. 지연이 크거나 트랜잭션이 전환을 막으면 실제 전환 작업은 실패할 수 있다. 상태와 사전 검증

다음은 공식 문서에 근거한 조회 예시다. 이 글에서는 클라우드 리소스를 생성하거나 명령을 실행하지 않았다. 프로젝트·리전·배포 이름은 자신의 환경에 맞게 바꾼다.

출력에서 상태, 대상 인스턴스의 연결 정보, errorDetail, 구성 차이를 확인한다. 이 조회에 복제 지연 수치가 포함된다고 가정하지 않는다. 프리뷰의 구성 차이 보기에는 DB 플래그 변경도 표시되지 않으므로 별도 대조가 필요하다. 조회 명령과 출력 필드

검증은 세 갈래로 나눈다

다음은 공식 기능을 실제 변경 관리에 적용하기 위한 운영 제안이다.

1. 기능: 대표 조회, 저장 프로시저, 문자·정렬·날짜 처리 등 업무 결과가 기대와 같은지 확인한다. 테스트의 외부 알림·결제 같은 부수 효과는 차단한다.

2. 성능: 동일한 조건으로 지연, 처리량, CPU·메모리·I/O를 비교한다. 성공한 쿼리 한 개로 전체 서비스의 개선을 단정하지 않는다.

3. 전환 복구: 연결이 끊겼을 때 재접속하는지, 재시도가 중복 쓰기를 만들지 않는지 확인한다. 전환 직전에는 복제 지연과 장기 트랜잭션도 따로 점검한다.

공식 문서도 green 환경에서 통합 테스트, 오류 로그, 자원 지표를 확인하도록 안내한다. 위 목록은 실제 측정 결과가 아니라 팀별 테스트 계획을 세우기 위한 예시다. 워크로드 검증 안내

이전 DB가 남아 있어도 바로 되돌릴 수 있다는 뜻은 아니다

전환 완료 후에는 blue에서 green으로의 논리 복제가 종료되고, 이전 blue는 독립된 읽기·쓰기 인스턴스가 된다. 따라서 이전 인스턴스를 남겨 둔 것만으로 새 운영 DB에 들어온 쓰기가 자동으로 보존되는 롤백 경로가 생겼다고 판단하면 안 된다. 앞 문장은 공식 수명주기 설명을 바탕으로 한 운영상 해석이다. 전환 후 수명주기

복구 계획에는 전환 후 신규 데이터를 어디서 회수할지, 어떤 조건에서 쓰기를 멈출지, 누가 정합성을 판정할지를 적는다. 전환 전 취소와 전환 후 복구는 다른 절차로 다뤄야 한다.

또한 green은 장애 발생 시 자동으로 승격하는 HA 대기 인스턴스가 아니다. 계획된 업그레이드와 재해 복구 설계를 혼동하지 않는다. 장애 전환과의 차이

마지막 단계는 삭제가 아니라 확인이다

기능 자체의 추가 요금은 없지만 blue와 green이 함께 존재하는 동안 각 인스턴스의 표준 요금은 발생한다. 안정성 확인 후 정리하되, 이전 DB를 영구 삭제하는 옵션을 무심코 복사해서 실행하지 않는다. 비용과 정리 동작

이 기능의 가치는 검증을 생략하는 데 있지 않다. 운영 트래픽을 유지한 채 검증할 시간을 확보하고, 전환 결정을 증거로 내릴 수 있다는 데 있다.

확인 범위

2026년 10월 30일 공식 발표와 제품 문서를 대조했다. 실제 Cloud SQL 배포, 전환 시간 측정, 비용 발생 테스트는 수행하지 않았다. 프리뷰의 제약과 명령은 도입 시점에 다시 확인해야 한다.