概要
現場で利用している RDS for MySQL のバージョンが 8.0 系であり、2026年7月末にサポートが終了予定 となっています。そのため、8.4 へのバージョンアップを検討する中で、Blue/Green Deployment（ブルーグリーンデプロイ） を活用することで、本番環境を停止せずに検証用環境を作成し、新バージョンでの動作確認が行えることを知りました。
Blue/Green Deployment についてはこれまで知識がなかったため、
AWS上で実際に検証環境を構築し、動作確認を行った手順と結果を本記事にまとめています。
同じように Blue/Green デプロイの動きを確認したい方や、
MySQL のバージョンアップを検討されている方の参考になれば幸いです。
この記事では、以下を目的に進めます。
・Blue/Greenデプロイの動作確認
・MySQL 8.0 → 8.4 の互換性・動作検証
・構築から削除までを最小コストで実施
前提
本番環境のMySQLのバージョンアップのため、作成する検証環境は以下の条件で作成しようと思います。
・MySQLバージョン：8.0と8.4で作成する
・費用はできる限り抑えられる構成で構築する（検証目的なので）
また、AWSのアカウント、IAMの権限など作成などはすでに作成してAWSでRDSが操作できる状態とします。
流れ
・RDS for MySQL 8.0 の作成手順（MySQL8.0）※Blue環境といわれるもの
・RDS Blue/Green デプロイで MySQL 8.4 環境を作成（Green環境）
・Greenへ接続して互換性チェックをする
・スイッチオーバーを実行してみる
RDS for MySQL 8.0 の作成手順（Blue環境）
ここでは、Blue/Green デプロイの「Blue」側となる MySQL 8.0 環境 を構築します。
検証目的のため、最小構成で作成します。
1️⃣ RDS データベース作成
AWS マネジメントコンソールから
「RDS」 → 「データベース」 → 「データベースの作成」をクリックします。
以下の設定を順に入力します。
| 項目 | 設定値 | 補足 |
|---|---|---|
| エンジンタイプ | MySQL | |
| エディション | MySQL Community Edition | |
| バージョン | MySQL 8.0.41（または最新の8.0系） | Blue用 |
| テンプレート | 開発／テスト | コスト抑制のため |
| DBインスタンス識別子 | mysql-blue-test |
任意でOK |
| ユーザー名 | admin |
|
| パスワード | 任意で設定 | |
| インスタンスタイプ | db.t4g.micro |
最小構成で十分 |
| ストレージタイプ | 汎用SSD（gp3） | |
| ストレージサイズ | 20GB | 最小限でOK |
| マルチAZ配置 | 無効 | 検証のため単一AZ |
| 自動バックアップ保持期間 | 1日 | コスト削減のため |
【画面イメージ】
2️⃣ 接続設定
RDSの「接続」セクションを以下の通り設定します。
| 項目 | 設定値 | 補足 |
|---|---|---|
| コンピューティングリソース | EC2 コンピューティングリソースに接続しない | RDS単体で運用するため |
| ネットワークタイプ | IPv4 | IPv6不要 |
| VPC | Default VPC（vpc-xxxxxxxx） |
検証用として最も簡単 |
| DBサブネットグループ | Default VPC のサブネットグループ | 自動選択でOK |
| パブリックアクセス | あり | 外部PCから接続できるようにするため |
| VPCセキュリティグループ | 新規作成 | 名前は任意 |
| アベイラビリティゾーン | 指定なし | 自動選択でOK |
| 認証機関 | デフォルト | そのままでOK |
3️⃣ セキュリティグループ設定（重要）
新しく作成されたセキュリティグループに、
MySQL接続用のインバウンドルール を追加します。
１．AWSコンソール → 「EC2」 → 「セキュリティグループ」 → 作成したvpc を選択
２．「インバウンドルールを編集」をクリック
３．下記ルールを追加：
| タイプ | プロトコル | ポート範囲 | ソース |
|---|---|---|---|
| MySQL/Aurora | TCP | 3306 | My IP（自分のIPアドレス） |
4️⃣ 作成の完了と確認
・ステータスが「利用可能（Available）」になるまで待機（約5〜10分）
・完了後、「接続とエンドポイント」欄から エンドポイント名 を控えます
例：mysql-blue-test.xxxxx.ap-northeast-1.rds.amazonaws.com
5️⃣ 接続テスト
RDSが起動したら、ターミナルまたはA5SQLから接続して確認します。
mysql -h mysql-blue-test.xxxxx.ap-northeast-1.rds.amazonaws.com -u admin -p
ログインできたら、以下のコマンドでバージョンを確認します。
SELECT VERSION();
出力例
+-----------+
| version() |
+-----------+
| 8.0.41 |
+-----------+
MySQL 8.0 で接続できれば、Blue環境の構築は完了です。
RDS Blue/Green デプロイで MySQL 8.4 環境を作成（Green環境）
作成した MySQL 8.0（Blue環境） を元に、
MySQL 8.4（Green環境） を構築し、
Blue/Greenデプロイによるスイッチオーバー（切り替え） の流れを検証します。
🧭 Blue/Greenデプロイとは？
AWS RDS Blue/Green デプロイは、
本番DB（Blue）と同一構成の新環境（Green）を自動で作成し、同期・切替を安全に行う仕組み です。
| 特徴 | 説明 |
|---|---|
| ✅ 安全なアップグレード | BlueとGreenの両方が同時稼働し、切り替え時に整合性を維持 |
| 🔁 自動同期 | Blue側で発生した更新データをGreenにレプリケート |
| ⚡ 短時間スイッチオーバー | 数十秒程度でDNS切替が完了 |
| 🧩 用途 | DBバージョンアップ・パラメータ変更・メンテナンス前検証など |
1️⃣ Blue/Greenデプロイの作成手順
① Blue環境を確認
RDSコンソールで以下を確認します。
・データベース名：作成したDB
・エンジンバージョン：MySQL 8.0.x
・ステータス：利用可能 (Available)
② デプロイ作成を開始
・AWS コンソール → RDS > データベース
・Blue環境（例：mysql-blue-test）を選択
・右上の「アクション」 → 「Blue/Green デプロイの作成」をクリック
③ 設定内容を入力
| 項目 | 設定値 | 補足 |
|---|---|---|
| ターゲットデータベースバージョン | MySQL 8.4 (LTS) | ここでバージョンアップを指定 |
| ターゲットインスタンスタイプ | db.t4g.micro |
Blueと同じでOK |
| ターゲットストレージ | gp3 / 20GB | Blueと同じでOK |
| マルチAZ配置 | 無効 | 検証のため単一AZで十分 |
| Blue/Green名 | mysql-bluegreen-test |
任意でOK |
最終確認画面
そのまま 「Blue/Greenデプロイの作成」 を実行します。
作成には数分かかります（5〜10分程度）。
④ Green環境の作成完了を確認
RDSの「Blue/Greenデプロイ」一覧に新しいデプロイが表示されます。
状態が 「同期中（In Sync）」 になったら準備完了です。
この時点で、AWSは内部的に以下を行っています👇
・Green側に新しいMySQL 8.4インスタンスを作成
・Blue側の変更を継続的にレプリケート
・スイッチオーバー待ち状態に保持
2️⃣ Green側に接続してデータを確認
・RDSコンソール → 「データベース」 → Green環境（例：mysql-green-test）を選択
・「エンドポイント」欄から接続先をコピー
・ターミナルまたはMySQL Workbenchから接続：
mysql -h mysql-green-test.xxxxx.ap-northeast-1.rds.amazonaws.com -u admin -p
3️⃣ バージョン差分の確認
SELECT VERSION();
出力例：
| 環境 | バージョン |
|---|---|
| Blue | 8.0.41 |
| Green | 8.4.0 |
→ これで、MySQL 8.4 (LTS) 環境が正常にデプロイされていることを確認できます。
データが同期されるか確認
Blue側にデータを登録して、Green側にデータが反映されるか確認してみます。
以下でテーブルの作成と仮データを入れて動きを見てみたいと思います。
# テーブル作成とデータの登録
CREATE DATABASE bluegreen_test;
USE bluegreen_test;
CREATE TABLE orders (
id INT AUTO_INCREMENT PRIMARY KEY,
product_name VARCHAR(100),
price INT,
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);
INSERT INTO orders (product_name, price)
VALUES ('keyboard', 2500), ('mouse', 1800), ('monitor', 22000);
# 確認SQL
USE bluegreen_test;
SELECT * FROM orders;
【blue側のordersのテーブル】
データが投入されていることが確認できます。
上記作成とほとんど同じタイミングでGreenのテーブルにも同じデータが反映されているはずなので、Green側のDBを確認してみます。
【Green側のordersのテーブル】
同じ内容のテーブルと値が作成されていることが確認できると思います。
もし追加で動作確認したい場合は、Blue側で「UPDATE/ DELETE」の操作や、「ALTER TABLE」などの操作を実施してGreen側が同じ内容になっているか確認してみてください。
8.0 と 8.4 の互換性チェック
今回こちらの記事では０からRDSを構築しているため、一部確認できない項目がありますが、
ChatGPTが提案していただいた、確認ポイントを参考として記載いたします。
認証方式の確認（mysql_native_password を使っていないか）
8.4 では、mysql_native_password はデフォルトで無効方向に寄っていて、
将来の 9.0 で完全削除予定の流れになっています。
Blue環境で、ユーザーの認証プラグインをチェックします。
SELECT user, host, plugin
FROM mysql.user;
plugin が caching_sha2_password ならそのままでOK
mysql_native_password を使っているユーザーがいれば、8.4のバージョンでログイン確認を行い、
いずれ ALTER USER ... IDENTIFIED WITH caching_sha2_password に寄せる方針を検討ください。
削除された機能・変数のチェック
MySQL 8.4 では、8.0 で 非推奨 だった一部機能・変数が削除されています。
① PASSWORD() 関数の削除
SELECT ROUTINE_SCHEMA, ROUTINE_NAME
FROM INFORMATION_SCHEMA.ROUTINES
WHERE ROUTINE_DEFINITION LIKE '%PASSWORD(%';
ストアド・トリガ・アプリSQL内で使っていないか確認します。
②tx_isolation 変数 → transaction_isolation に統一
SHOW VARIABLES LIKE 'tx_isolation';
SHOW VARIABLES LIKE 'transaction_isolation';
パラメータグループやアプリ設定で tx_isolation を参照していないかを確認します。
③expire_logs_days → binlog_expire_logs_seconds へ置き換え
SHOW VARIABLES LIKE 'expire_logs_days';
SHOW VARIABLES LIKE 'binlog_expire_logs_seconds';
RDSパラメータグループで expire_logs_days を使っていないかを確認します。
④FLOAT/DOUBLE に AUTO_INCREMENT が付いているカラムはエラーになる
SELECT TABLE_SCHEMA, TABLE_NAME, COLUMN_NAME
FROM INFORMATION_SCHEMA.COLUMNS
WHERE DATA_TYPE IN ('float','double')
AND EXTRA LIKE '%auto_increment%';
上記に該当がないか確認をします。
外部キー制約まわり
8.4 では、外部キーが参照する親テーブル側に ユニークキーがきちんと定義されているか がより厳しく見られるようになっています。
本番でそのような怪しいFKを持っていそうなら、検証環境にスキーマを近づけた上で、テーブル作成やALTERを試すのが安全です。
実アプリに近いクエリを 8.0 / 8.4 双方で流して結果比較
・代表的な SELECT / UPDATE / INSERT / DELETE（レポート系・画面表示系・バッチ系）をピックアップ
・Blue と Green にそれぞれ接続して同じSQLを投げる
・結果件数・エラー有無・実行時間の差を確認
スイッチオーバーの対応
スイッチオーバー前に確認すること
| チェック項目 | 内容 | 推奨状態 |
|---|---|---|
| Blue/Greenデプロイの状態 | RDSコンソール → 「Blue/Greenデプロイ」画面で状態を確認 | 「同期中（In Sync）」 |
| Blue環境への書き込み | 現在も INSERT/UPDATE が正常に反映されているか | ✅ 確認済みならOK |
| Green環境の確認 | SELECTでデータが同期されているか | ✅ 同一データが見える状態 |
| アプリ接続やクライアント | Blueに接続しているアプリ・ユーザを停止または退避 | ⚠️ 検証環境なら不要だが注意 |
スイッチオーバー実施手順（GUI操作）
切り替え対象のDBを選択し、「アクション」 ⇒ 「切り替え」を選択してください。
切り替え画面になるので、内容を確認して「切り替え」を選択してください。
切り替え処理が稼働します。完了までにしばらく時間がかかります。
しばらくすると、スイッチオーバが完了したメッセージが表示されます。
完了すると、RDSの表示が変わります。
青いB：切り替え前のGreen環境になります。
黒いB：切り替え前のBlue環境になります。
スイッチオーバー確認
画面からMySQLのバージョンを確認してみます。
青いBが8.4のバージョンになっていることが確認できます。
黒いBが8.0と古いバージョンになっていることが確認できます。
SQLでも確認してみます。画面ではA5SAQで確認をしてみたいと思います
新Blue環境に接続して、SQLを実行
SELECT VERSION();
バージョンが8.4であることが確認できます。
INSERT文についても確認しています。
USE bluegreen_test;
INSERT INTO orders (product_name, price) VALUES ('switch-test', 7777);
追加前
追加後
正常に追加されていることを確認できる
補足
旧Blueにも追加を行ってみる。
以下のエラーが出力されます。※こちらは想定通りとなります。
ERROR 1290 (HY000): The MySQL server is running with the --read-only option so it cannot execute this statement
MySQLが「読み取り専用モード（read-onlyモード）」で起動しているため、
INSERT, UPDATE, DELETE, CREATE, DROP, ALTER などの書き込み系操作が禁止されている状態を意味します。
なぜBlue環境が「read-only」になるのか
AWS RDS Blue/Greenデプロイでは、
スイッチオーバー実行時に以下の挙動 が自動で行われます。
| 処理順 | 動作内容 | 対象環境 |
|---|---|---|
| ① | Blue環境を一時停止し、最終的なトランザクションをGreenに同期 | Blue |
| ② | Green環境を新しい本番（Primary）として昇格 | Green |
| ③ | Blue環境を read-only モードに変更し、以降は更新禁止にする | Blue |
| ④ | Blue環境を「旧バージョンのバックアップ／リストア用インスタンス」として残す | Blue |
スイッチオーバー完了後のBlueは「参照専用の過去環境」 という扱いになります。
これは、AWSにてデータの「整合性維持」と「誤更新防止」が理由とのことです。
スイッチオーバー後もBlueで書き込みできてしまうと、以下の問題が発生するため未然に防止しているとのことです。
・GreenとBlueでデータが分岐する
・「どちらが最新か分からない」状態になる
・復旧・監査時に混乱する
なお、上記の設定は旧Blue側の環境で以下SQLを実行することで確認ができます。
SHOW VARIABLES LIKE 'read_only';
SHOW VARIABLES LIKE 'super_read_only';
SHOW VARIABLES LIKE 'read_only';
SHOW VARIABLES LIKE 'super_read_only';
まとめ
本記事では、RDS Blue/Green デプロイの検証環境を実際に構築し、
スイッチオーバーまでの一連の動作を確認しました。
初めての取り組みでしたが、実際に環境を構築して動きを確認できたことで、
Blue/Green デプロイの仕組みをより具体的に理解することができました。
本番環境では、データ量や連携アプリケーション、システム規模などが異なるため、
切り替え時の検証項目や所要時間などは環境に応じて追加の確認が必要になると思います。
それでも、今回の検証を通して Blue/Green デプロイの手軽さと安全性の高さ を実感できました。
今後、本番適用に向けてさらなる調査や検証を進める際には、
新たに得られた知見をこの記事に追記していきたいと思います。
本記事の内容について、不足や誤りが見つかった場合は随時修正していきます。