MySQL HeatWaveのブルー/グリーン切替検証：接続・参照・書き込みはいつ再開できるか

はじめに

2026年8月25日にMySQL HeatWaveでもブルー/グリーン・デプロイ（以下、BGデプロイ）がリリースされました。
Oracle Cloud Infrastructureドキュメント/リリース・ノート – HeatWave: ブルー/グリーン・デプロイ

BGデプロイでは、稼働中のBlue環境とは別にGreen環境を準備し、検証してから切り替えられます。
利用するうえで気になるのは、「Green環境への切替中にアプリケーションの接続・操作がどうなるか」という点です。

今回の検証では、スイッチオーバー時にトランザクション開始要求や既存接続の利用可否を確認する処理が応答待ちとなり、その後、接続が切断される挙動、および接続断後の再接続を観測しました。GreenでSELECTが成功した後もINSERTは失敗し、読み取り専用の解除を確認した後にINSERT・COMMITが成功しました。

今回の対象と検証条件

今回は、MySQL 8.4.8のBlue環境から9.7.2のGreen環境へのスイッチオーバーを対象に、接続・SELECT・INSERTの挙動を確認しました。BlueとGreenはいずれもスタンドアロンDBシステムです。

BGデプロイでは、BlueからGreenへ変更を同期し、スイッチオーバー時にプライマリエンドポイントをGreenへ引き継ぎます。この間、書き込みが停止され、クライアント接続が中断される場合があります。

今回は、スイッチオーバー中にアプリケーションの接続・操作がどうなるかを検証します。

検証条件

検証では、切替前から使用しているプライマリエンドポイントに対し、管理者ユーザーadminとアプリ用ユーザーappで、次の2種類の処理を、スイッチオーバー中も継続的に実行しました。

各処理は、以下の2種類の接続方式で実行しました。

• 新規接続：試行ごとに接続し、SQL実行後に切断します。エラーが発生した場合は接続を破棄し、次の試行で新たに接続します。

• 継続接続：同じ接続を再利用してSQLを繰り返し実行します。接続不能やエラーを検知した場合は、接続を破棄して再接続します。

各試行では、以下のSELECTでサーバー情報と読み取り専用変数などを取得しました。
接続先がBlueとGreenのどちらかは、取得した @@hostname と @@version を、事前に確認した各環境の値と照合して判定しました。

また、OCI CLIでBlue/GreenのDBシステムとBGデプロイメントの状態を約1秒間隔で取得し、スイッチオーバー開始～終了までの状態遷移を監視しました。CLIは約1秒間隔の観測であり、状態が変化した瞬間を示すものではありませんのでご了承ください。

検証：スイッチオーバー中に接続・DML操作(参照/更新)はどうなるのか

結論として、今回の検証では接続・参照・更新はGreen切替後に別々に回復しました。

簡単に流れを説明すると以下の通りです。

1. スイッチオーバー開始後、Blueへの接続/クエリ実行の応答待ちが発生

2. エンドポイントがGreenへ切り替わり、新規接続に成功

3. Greenへ接続再開後、SELECTが成功（ただし、読み取り専用のためINSERTは失敗）

4. 応答待ちになっていた全ての接続はコネクションロストし、再接続処理で接続成功

5. 読み取り専用（read_only）の解除後、INSERT・COMMITが成功

また、CLI で取得するGreen環境DBシステムのデータベースモードのREAD_WRITE表示は、実際の書き込み成功より後に観測される結果となりました。

以下に詳細を記載します。

ポイント1. 切替時に何が起きたか

スイッチオーバー開始後のCLIとSQLの結果を重ねた時系列を以下に示します。
ここでは、プライマリエンドポイントに対して「いつから参照・更新を再開できるようになったか」の流れを整理します。
（★は接続待機、接続タイムアウト、再接続成功に関するものです）

まず、スイッチオーバーが開始しても数分はBlue環境への接続・クエリ実行が成功しています（No.1・2）。

その後、Blue環境への新規/継続接続で接続中の処理は、トランザクション開始要求の応答待ち・カーソル作成時の内部PING応答待ち状態になります(No.3)。

カーソル作成時の内部PING応答待ちとは、SELECTなどを実行するためのカーソル作成時に、Connectorの内部処理で通信確認(is_connected())としてMySQL ServerにPINGを送信し、その応答待ちとなる状態です。

その後、新たな接続の試行ではConnectorのconnection_timeout設定時間を超えたため、接続確立が失敗しました（No.4）。

CLI上ではBlue環境のエンドポイントに従来のIPアドレスが設定されている状態でしたが、この時点で接続がブロックされるという結果になりました。

その後、Green環境へのエンドポイント切り替え(No.5)を契機に、Green環境への新規接続に成功します（No.6）。
この時点では、Greenは読み取り専用(super_read_only=1、read_only=1 ）のためSELECTのみ成功します（No.7）。

Blueのエンドポイントが空になると（No.8）、No.3で応答待ちになっていた接続は全てコネクションロストし、クライアント側で切断を検知します（No.9）。

切断後、継続接続方式でも、再接続に成功します（No.10）。

書き込み再開（No.12）と対応したのは、読み取り専用変数（ super_read_only、read_only ）の解除（No.11）です。
ちなみに、adminユーザー、appユーザーはほぼ同時に書き込みが再開されており、明確な時間差は確認できませんでした。

また、INSERT・COMMIT成功時（No.12）もCLIではDBシステムのデータベースモードは READ_ONLY と表示されており、約31秒後にCLIでREAD_WRITEを観測しました（No.13）。

つまり、CLIでデータベースモード変更を観測する前には既に内部的に読み書き可能になっている状態でした。

旧Blue環境はDBシステムのデータベースモードREAD_ONLY、アクセスモードRESTRICTEDへ変更され（No.15）、管理者ユーザーのみアクセス可能かつ読み取り専用サーバーに更新された後、スイッチオーバー完了（No.16）という結果を観測しました。

また、本記事に記載した待機時間と回復順序は、本検証環境での観測結果であり、サービスの仕様値や復旧時間を保証するものではありません。

ポイント2. 応答待ちになった新規接続/継続接続は切断後、再接続して復旧した

今回の検証では、スイッチオーバー中にBlueへの接続が応答待ちになり、接続確立時のタイムアウトや、応答待ちだった接続の切断を検知しました。Greenへエンドポイントが切り替わると、再接続が成功しました。
そのため、アプリケーションでは、接続エラーや接続不能を検知した場合に再接続できることと、再接続後に必要なSQLが成功することを確認しておく必要があります。

また、スイッチオーバー実行前からBlue上で実行していたトランザクションについても、カーソル作成時のConnector内部処理で行われる通信確認中に接続が失われ、クライアント側で接続が破棄されました（No.9）。
未コミットの変更はロールバックされ、Greenへの再接続は新しいセッションとして確立されました。

つまり、元のセッションはGreen環境へ引き継がれず、処理を再実行する場合はアプリケーション側で再接続後に新しいトランザクションとして最初から実行する必要があります。

また、Blue環境へアプリケーションからCOMMITが送信されそのCOMMIT応答を受信できなかった場合は、すでにBlue環境でコミットされている可能性があります。このような場合、アプリケーションは処理結果を検証するか、重複実行を防ぐために冪等的に再試行する必要があります。

なお、接続処理の所要時間はクライアントの実装や設定の影響も受けるため、本記事ではサービス全体の停止時間としては評価していません。

切替後の注意：旧Blueへ接続先を戻すだけでは切り戻せない

注意事項として、スイッチオーバー後の旧Blue環境のエンドポイントはGreen環境のIPアドレスに変わり、アクセスモード:RESTRICTED（管理者ユーザーのみアクセス可）、データベースモード:READ_ONLY（読み取り専用）になります（No.15）。

また、スイッチオーバー後、BGデプロイが自動作成したレプリケーション・チャネルは削除されます。
Green -> 旧Blue へのレプリケーションも自動設定されないため、Green環境への更新は旧Blue環境へ反映されません。

そのため、旧Blue環境が残っていても、接続先を戻すだけで更新データを保った切り戻しはできません。復旧方針は切替前に検討しておく必要があります。

なお、スイッチオーバー後に、Green -> 旧Blue のレプリケーションが可能な場合がありますが、MySQL 公式ドキュメントにもある通り、新しいソースから古いレプリカへのレプリケーションはサポート対象外であり、この構成を利用した切戻しや継続的な動作を保証するものではありません。

Replication from newer sources to older replicas might be possible, but is generally not supported.
（機械翻訳）新しいソースから古いレプリカへのレプリケーションが可能な場合もありますが、一般的にはサポートされていません。

（引用）MySQL 9.7 Reference Manual – 19.5.2 Replication Compatibility Between MySQL Versions

ただし、ソースとレプリカでバイナリログ形式が同じで、両方が行ベースのレプリケーションをサポートしており、レプリカには存在しないSQL機能に依存するDDLがレプリケートされない場合、行ベースのレプリケーションを使用してDMLの効果をレプリケートできると上記公式ドキュメントにも記載があります。

MySQL 9.7.2（Green） から8.4.8（Blue） へのレプリケーションチャネルを作成する場合、以下の手順で作成できます。

1. 旧Blue環境のアクセスモードをUNRESTRICTED(すべてのユーザーからアクセス可)に変更
   ※本コマンドでは、データベースモードは読み取り専用（READ_ONLY）から変更はしません。

   oci mysql db-system update \ --db-system-id <MDSのOCID> \ --access-mode UNRESTRICTED

   1 2 3

   oci mysql db-system update \   --db-system-id <MDSのOCID> \   --access-mode UNRESTRICTED

2. Greenをソース、旧Blueをレプリカとしたレプリケーションチャネルを作成
   作成手順は下記公式ドキュメントを参照してください。
   [Oracle Cloud Infrastructureドキュメント-レプリケーション・チャネルの作成]

まとめ

本検証では、接続・参照・更新はGreen切替後に別々に回復することが分かりました。 そして、CLIの状態表示と実際のSQLの成功には時間差がありました。

スイッチオーバー実行時は、再接続とSELECTの成功だけで復旧と判断せず、必要な書き込みとCOMMITまで確認しましょう。 COMMITの応答を受け取れなかった場合は、処理が反映済みの可能性もあります。業務キーなどで結果を確認し、再試行による重複を防ぐ必要があります。
また、切替前のトランザクションはGreen環境へ引き継がれず、処理を再実行する場合はアプリケーション側で再接続後に新しいトランザクションとして最初から実行する必要があります。

BGデプロイによって新環境の準備を稼働中のBlueと並行して進められますが、切替時の接続・書き込み中断への備えは必要です。

ぜひ、皆さんもBGデプロイ機能を検証してみてください！