【Aurora MySQL】パラメータグループ変更（binlog_format）を伴うB/Gデプロイメント実行手順

はじめに
B/Gデプロイメントの活用ケースと検証構成
問題：binlog_format = OFF だと B/G デプロイメントが作れない
作業フロー全体像
詳細手順
切り戻し方法
- Green 環境を削除する場合
- binlog_format を元に戻す場合
まとめ

はじめに

こんにちは！クロスインダストリー第2本部の加治屋です。

AWSのコスト最適化やメンテナンスの一環として、Amazon Aurora MySQL のインスタンスクラスをx86ベースからGravitonへ移行したり、データベースのバージョンアップを行ったりする機会は多いかと思います。

その際、ダウンタイムを最小限に抑えられる便利な機能がB/G（ブルー/グリーン）デプロイメントです。しかし、作成時にAurora特有の「クラスターパラメータグループの制約」に遭遇することがあります。

今回は、その際のエラー内容と、実際の対応手順をブログとしてまとめます。同様の作業を検討している方の参考になれば幸いです。

B/Gデプロイメントの活用ケースと検証構成

B/Gデプロイメントは、以下のようなデータベースの変更作業を安全かつ低ダウンタイムで行いたい場合に有効です。

インスタンスクラスの変更（例：x86からARM/Gravitonへの移行、スペックアップ/ダウン）
エンジンのマイナー/メジャーバージョンアップ
その他のパラメータグループやストレージ設定の変更

今回は、「db.r5.xlarge（x86_64）からdb.r6g.xlarge（Graviton2）への移行」を具体的な一例として手順を解説しますが、バージョンアップ等の場合も全体の流れは同じです。今回の移行対象は以下の通りです。

エンジンバージョン: Aurora MySQL 3.04.1 (MySQL 8.0互換)
移行前: db.r5.xlarge（x86_64）
移行後: db.r6g.xlarge（ARM / Graviton2）

問題：binlog_format = OFF だと B/G デプロイメントが作れない

Auroraにおけるクラスターパラメータグループの binlog_format はバイナリログの記録形式を指定するパラメータです。

B/Gデプロイメントではデータの同期（レプリケーション）を行うため、変更履歴を行単位で厳密に記録する ROW 形式での有効化が必須となります。また、binlog_format は静的（Static）パラメータであるため、この設定を変更して有効化するにはクラスターの再起動が必要になります。

そのため、binlog_format = ROW 以外の状態（OFF や MIXED・STATEMENTなど）でB/Gデプロイメント作成画面を進めると、以下の警告が表示されます。

ブルーパラメータグループのパラメータ値を修正（再起動が必要）

ブルー/グリーンデプロイを正常に作成するには、特定のパラメータ設定が必要です。
RDS にパラメータの値を修正させてデータベースを再起動させることも、
パラメータグループ設定で手動更新することもできます。

上記のエラーが表示された際、RDS にパラメータの値を修正させてデータベースを再起動させる手順は以下の通りです。

作業フロー全体像

[1] B/G デプロイメント作成画面を開く
        ↓
[2] binlog_format 警告を確認 → チェックボックスをオン
        ↓
[3] パラメータ変更確認ポップアップで「確認」と入力 → 続行
        ↓
[4] 「再起動して作成」をクリック
        ↓ ここでクラスター再起動が発生（Blue 環境）
[5] Green 環境の作成完了を待機（数十分）
        ↓
[6] 【オプション】Green 環境の各種構成変更（インスタンスクラスやバージョン等）
        ↓
[7] Green 環境の接続確認
        ↓
[8] スイッチオーバー（本番切り替え）

詳細手順

1. B/G デプロイメント作成画面を開く

RDS コンソール（https://console.aws.amazon.com/rds/）を開く
左メニュー「データベース」から対象の Aurora クラスターを選択
「アクション」→「ブルー/グリーンデプロイの作成」をクリック

2. binlog_format 警告への対応

画面下部に以下の警告が表示されたら、「ブルーパラメータグループを修正（再起動が必要）」のチェックボックスをオンにして「次へ」をクリックします。

補足

この画面で指定できるのは、グリーンデータベースの「エンジンバージョン」と「各種パラメータグループ」のみです。インスタンスクラス（Gravitonへの移行）やストレージ設定を変更したい場合は、まずこのままGreen環境を作成し、立ち上がった後のGreenインスタンスに対して個別に「変更」を行う必要があります（詳細はステップ6を参照）。

3. パラメータ変更確認ポップアップ

ポップアップが表示されるので、内容を確認します。

項目	内容
グループ名	`blue-green-params-XXXXXXXXXXXX`（自動生成）
パラメータグループファミリー	`aurora-mysql8.0` など
新しいパラメータセット	`binlog_format = ROW`

内容を確認したら入力欄に「確認」と入力し、「続行」をクリックします。

4. 「再起動して作成」をクリック

「見直しと確認」画面で構成を確認し、「再起動して作成」をクリックします。

RDSによるパラメータグループの作成・アタッチ・クラスターの再起動が自動的に実行されます。

5. Green 環境の作成完了を待機

Green 環境のライター・リーダーインスタンスの両方のステータスが「利用可能」になるまで待ちます（数十分かかる場合があります）。

6. Green 環境の各種構成変更（オプション）

起動直後のGreen環境は、Blue環境と同じ構成（インスタンスクラスなど）になっています。「Gravitonへの移行」「インスタンスクラスの変更」「その他設定の変更」を行いたい場合は、ここで個別に実施します。
（※バージョンアップ等の目的で、すでにステップ2でバージョンを指定済みの場合は、このステップをスキップしてステップ7へ進んでください）

RDS コンソールで Green 環境の変更したいインスタンスを選択します。
「変更」をクリックします。
必要に応じて「DB インスタンスクラス」などを選択します（例：Gravitonへ移行する場合は db.r6g.xlarge などを選択）。
「続行」→「すぐに適用」→「DB インスタンスを変更」をクリックします。
インスタンスのステータスが「利用可能」に戻るまで待機します。

7. Green 環境の接続確認

Amazon EC2 または AWS CloudShell から Green 環境のインスタンスに接続し、以下を確認します。

DB インスタンスに接続できること
SQL クエリが正常に実行できること

8. スイッチオーバー（本番切り替え）

RDS コンソールの左メニュー「データベース」から、対象のデプロイメント（例：bg-deployment-1）を選択
「アクション」➔「切り替え（スイッチオーバー）」をクリック
スイッチオーバーの確認画面が表示される。「スイッチオーバーのタイムアウト期間(※)」（デフォルトは5分）を設定できる。
※切り替え時に未完了の重いトランザクションが残っている場合、このタイムアウト期間を超えると安全のために処理がロールバックされ、切り替えが自動キャンセルされる仕組み
内容を確認し、「切り替え」をクリックして実行

切り戻し方法

もし作業中に問題が発生した場合、あるいは作成した環境を一度リセットしたい場合の切り戻し手順です。

Green 環境を削除する場合

RDS コンソール → 左メニュー「ブルー/グリーンデプロイ」から対象を選択し、「アクション」→「削除」をクリックします。
※Blue 環境（本番）には影響しません。

binlog_format を元に戻す場合

RDS が自動作成した新パラメータグループが Blue 環境にアタッチされている場合、元のパラメータグループに戻す手順は以下の通りです。

対象の Aurora クラスターを選択 → 「変更」
「DB クラスターパラメータグループ」を元のグループに変更
「すぐに適用」→「DB クラスターを変更」
ライターインスタンスを再起動
パラメータグループが元に戻っていることを確認

まとめ

Aurora MySQL の B/G デプロイメントにおいて、クラスターパラメータグループの binlog_format 設定（デフォルトの OFF など）が思わぬ障壁になります。ただし、RDS がパラメータグループの作成・アタッチ・再起動を自動でやってくれるため、手順を理解していれば安全に対処することが可能です。

これからAuroraのGraviton移行やマイナーバージョンアップでB/Gデプロイメントを利用される方の参考になれば幸いです。
最後までお読みいただきありがとうございました！