業務システムのデータベースをMySQL 8.0から8.4へ上げたい。けれども、版上げの作業は休日の深夜に停止の時間を取って行うもので、もし問題が出たらバックアップから戻すしかない。Google Cloudのブログも、メジャーバージョンの更新には部署をまたぐ数週間の調整、狭いメンテナンスの時間枠、数時間の停止が伴うと書き、先送りは脆弱性への対応の遅れにつながると指摘しています。
Google Cloudは2026年10月28日のブログで、Cloud SQL for MySQLの「ブルーグリーンデプロイ」をプレビューとして告知しました。リリースノートでは、10月8日の項に載っています。本番のデータベース（ブルー）のコピー（グリーン）を新しい版に上げて同期させ、準備ができたら短い停止で切り替える仕組みです。この記事では、公式のブログとドキュメントから、何が自動になるのか、切り替えの前に何を確かめるのかを整理します。
ブルーとグリーンで、何が自動になるか
ブログによると、Cloud SQLのブルーグリーンデプロイは次の3つの段階で動きます。
- ブルー（本番）: 今のプライマリのインスタンス。切り替えまで、通常どおりアプリケーションの処理を受け付ける
- グリーン（準備）: ブルーの一時的な複製。Cloud SQLが指定した版に上げ、継続的なレプリケーションでブルーと同期させる
- 切り替え（switchover）: Cloud SQLがブルーを短い時間だけ読み取り専用にし、最後の同期を終えてから、グリーンを新しいプライマリに昇格させる
ブログが挙げる特徴は3つです。
- 切り替えの停止が短い: ドキュメントによると、切り替えの停止はCloud SQL Enterprise Plusで通常1秒未満、Enterprise版で通常60秒未満です。Enterprise版の時間は、処理の量とレプリケーションの遅延によって変わります
- アプリケーションの変更が要らない: 切り替えのとき、Cloud SQLは既存のIPアドレス、インスタンス名、バックアップを新しいデータベースへ移します。接続文字列や設定ファイルを書き換える必要はない、とされています
- 本番のデータで試せる: 切り替えの前に、グリーンに対して実際のアプリケーションの処理やクエリを流して性能を確かめられます。問題があれば、切り替えの前にデプロイを削除すれば、本番のデータベースには触れません
切り替えの後も、古いブルーを手動の戻し先として残せます。ドキュメントによると、古いブルーは読み書きのできる独立したインスタンスとして残り、費用もかかり続けます。
対象と条件
ドキュメントとブログに書かれている条件を、使う前に確かめる順にまとめます。
- 提供段階: プレビュー。Pre-GAの条件が適用され、サポートが限られる場合がある
- 対象: Cloud SQL for MySQLのスタンドアロンのプライマリのインスタンス（高可用性の構成を含む）
- 版: メジャーバージョンの更新はMySQL 8.0から8.4まで。版を変えない設定やハードウェアの変更は、MySQL 5.7以降で使える。MySQL 8.0.18は対象外
- 前提: 自動バックアップとバイナリログが有効で、最新のメンテナンスのバージョンで動いていること。新しいネットワークアーキテクチャのインスタンスであること
- 使えない構成: リードレプリカがあるインスタンス、Private Service Connectの送信の構成、IAMグループ認証
- 料金: 機能そのものに追加の料金はない。ただし、ブルーとグリーンの両方があるあいだ、両方に通常の料金がかかる。切り替えの後も、古いブルーを消すまで2台分の料金が続く
- ほかのエンジン: ブログはPostgreSQLへの対応を「coming soon（近日）」と書いている。ドキュメントの現時点の記載では、PostgreSQLとSQL Serverは対象外
- 操作: Google Cloudのコンソール、
gcloud、Cloud SQL Admin APIのいずれかで行う
リードレプリカがあるインスタンスで使うには、先に構成を見直す必要があります。切り替えは計画した作業のための仕組みで、グリーンは障害時の切り替え先にはなりません。利用できるリージョンの一覧は、開いたドキュメントにはありません。ドキュメントは、リージョンやゾーンの計算資源の状況によって、インスタンスの作成が影響を受けることがあるとだけ書いています。
CLIでの流れ
ドキュメントの手順に沿ったCLIの例です。デプロイ名、インスタンス名、リージョンは例の値です。
# 同期した、新しい版のグリーンを作る
gcloud beta sql blue-green-deployments create my-upgrade \
--source-instance=prod-mysql-db \
--target-database-version=MYSQL_8_4 \
--region=us-central1
# 状態とグリーンの接続先を確かめる
gcloud beta sql blue-green-deployments describe my-upgrade \
--region=us-central1
# グリーンに接続して試す
gcloud sql connect TARGET_INSTANCE_NAME --user=DB_USER
# 本番の処理をグリーンへ切り替える
gcloud beta sql blue-green-deployments switchover my-upgrade \
--region=us-central1
# 準備ができたら古いデータベースを片付ける
gcloud beta sql blue-green-deployments delete my-upgrade \
--region=us-central1 \
--delete-old-sourceブログの例は beta のない gcloud sql blue-green-deployments と書かれていますが、ドキュメントとCLIのリファレンスは gcloud beta sql blue-green-deployments です。このPCのgcloud 588.0.0（2026年11月6日時点の最新は592.0.0）で gcloud sql blue-green-deployments --help を実行すると、Invalid choice のエラーになりました。beta の付くコマンドは、betaコンポーネントが入っていなかったため実行していません。
作成のとき、版上げであればCloud SQLが事前チェックを自動で実行し、問題があれば作成は止まります。ドキュメントは、先に事前チェックを単独で流して問題を洗い出すことも勧めています。describe に --show-config-diff を付けると、ブルーとグリーンの設定の差を見られます。ただしプレビューの間は、データベースフラグの差は表示されません。
最後の delete の動きは、切り替えの前と後で違います。切り替えの前はグリーンが消え、ブルーはそのまま残ります。切り替えの後は、既定で両方のインスタンスが残り、--delete-old-source を付けたときだけ古いブルーが完全に消えます。ここからは編集部の提案ですが、切り替えの後しばらくは古いブルーを戻し先として残すという特徴を生かすなら、このコマンドを切り替えと同じ作業の中で続けて実行しないほうが安全です。ドキュメントも、切り替えの後の確認が終わるまでブルーを残すよう案内しています。
切り替えの前に確かめること
ブルーグリーンの仕組みは、データの同期と切り替えを自動にしますが、新しい版でアプリケーションが正しく動くかまでは保証しません。1と3はドキュメントの案内をもとに、2、4、5は編集部の提案として、確認の項目を挙げます。
- アプリケーションの主要な処理を流す: ログイン、検索、帳票の出力、夜間の集計など、業務で止まると困る処理を、グリーンに向けて実行します。ドキュメントは、結合テスト、エラーログの非推奨の構文の警告、CPU・メモリ・I/Oの確認を挙げています
- 書き込みの扱いを確かめる: グリーンへの試験で書き込みをしてよいか、同期にどう影響するかは、ブログにもドキュメントにも明記されていません。ドキュメントはグリーンを「特殊なリードレプリカ」と説明しているので、確認が取れるまでは読み取りの処理を中心に試します
- 切り替えの条件を整える: 状態が
SWITCHOVER_READYでも、レプリケーションの遅延は判定に入っていません。遅延が大きいと、切り替えは失敗します。describeには遅延が出ないので、Cloud Monitoringのreplica_lagなどで確かめます。長く動くDDLやバッチの書き込みも、先に終わらせます。ドキュメントは、書き込みの少ない時間帯に切り替えるよう勧めています。失敗したときは、処理はブルーに残ります - 短い停止に備える: 切り替えのとき、ブルーは短い時間だけ読み取り専用になり、接続も短く切れます。その間に書き込みが失敗したとき、アプリケーションが再試行するか、利用者にエラーを見せるかを確かめておきます。Enterprise版の60秒未満という目安で、処理が耐えられるかも見ます
- 戻す手順を決めておく: 切り替えの前なら、デプロイを削除すれば本番はそのままです。切り替えの後は、古いブルーを残しておく期間と、戻すときの判断の基準を、作業の前に決めておきます。切り替えの時点でブルーからグリーンへのレプリケーションは終わります。切り替えの後に新しいプライマリへ書かれたデータを古いブルーへ戻す仕組みは、開いたドキュメントには書かれていません
MySQLの新しい版では、同じSQLでも結果が変わることがあります。版上げの受け入れ確認の考え方は、MySQL 9.7のDATE挙動変更 — 数字だけが静かに変わる更新で扱いました。本番のデータベースを別の用途から読ませるときの分離の考え方は、AIエージェントに本番DBを読ませる — AlloyDB新プレビューも参考になります。
確認した範囲
2026年11月6日に、Google Cloud公式ブログの「Near-zero downtime upgrades: Announcing Cloud SQL for MySQL blue-green deployments」（2026年10月28日）、Cloud SQL for MySQLのリリースノート、ブルーグリーンデプロイのドキュメント（概要、作成、確認、切り替え、削除）、
gcloud beta sql blue-green-deploymentsのリファレンスを直接開いて確認しました（資料調査）。Cloud SQLのインスタンスを作っての検証はしていません。CLIで実行したのは、このPCのgcloud 588.0.0での--helpの確認だけです。グリーンへの書き込みの扱い、利用できるリージョンの一覧、切り替えの後に古いブルーへ戻す具体的な手順は確かめられていません。片付けの注意と、切り替えの前の確認のうち提案と書いた項目は、編集部の提案です。
業務システムのデータベースの版上げの計画、切り替えの前の確認の設計は、開発・AI・自動化のご相談からお問い合わせください。
参考資料
- Near-zero downtime upgrades: Announcing Cloud SQL for MySQL blue-green deployments（Google Cloud Blog、2026年10月28日）
- Cloud SQL for MySQL release notes（Google Cloud Documentation）
- About blue-green deployments in Cloud SQL（Google Cloud Documentation）
- Create and stage a blue-green deployment（Google Cloud Documentation）
- Perform a blue-green deployment switchover（Google Cloud Documentation）
- Delete a blue-green deployment（Google Cloud Documentation）
- gcloud beta sql blue-green-deployments（Google Cloud SDK）
