【概要】

Aurora1.22.2（MySQL5.6互換）についてAurora2（MySQL5.7）世代への強制アップグレード予告が来た。
対象のスナップショットから検証環境を立て、単純にインプレースアップグレードをしたところ5時間弱かかった。
2022年末に公開されたAuroraのBlue/Greenデプロイで対応できないか検証したところ、停止時間は5分と大幅に短縮された。
※停止があるのは最初のbinlogを有効にする際の瞬断（1分未満）およびスイッチオーバー（切り替え）時の4分だった

■用語

– Blue:変更前、ここでいうとAurora1環境
– Green:変更後、ここではAurora2になった環境
– Switchover：BlueへのトラフィックをGreenに切り替える

※スイッチオーバーするまでの間はDBはBlueからGreenにレプリケーションし続ける必要がある。

【おおよその理解】

Auroraに対して「ブルー/グリーンデプロイ」を実行すると、裏側ではbinlogを出してBlue→Greenへのレプリケーションを開始する。そのうえでクローンをインプレースアップグレードし、その後レプリケーションを再開していると思われる。これまで手作業でやっていたもの（例：https://dev.classmethod.jp/articles/enable-aurora-binary-logs/）でやってることを自動でやっているものと推察される。

■ハマリポイント

作業としては既存のAuroraクラスタを選択してブルー/グリーンデプロイの作成を行うだけだが以下2点のハマりポイントがある。
– 1)Blue側のクラスタ用パラメータグループでバイナリログを出す設定にして反映しておく必要がある（binlog_format MIXEDにして再起動）
– 2)ブルー/グリーンデプロイ設定前にBlue側でバイナリログを発生させておく必要がある

【作業手順】

■ハマリポイント回避のための事前準備

1)Blue側のクラスタ用パラメータグループでバイナリログを出す設定にして反映しておく

binlog_formatがOFFの状態でB/Gデプロイを作成しようとすると
Blue Green Deployments requires cluster parameter group has binlog enabled.
というエラーになってしまう。メッセージにある通りbinlogが有効になっている必要があるため、クラスタのパラメータグループでbinlog_formatを有効にする必要がある。

パラメータグループの変更
Blue環境にアタッチされているクラスタ用パラメータグループを編集し

binlog_format MIXED

とする

★インスタンス再起動で反映★
上記のままだとDBクラスターのパラメータグループが「再起動を保留中」のままで反映されていないため、インスタンスを再起動する。
[アクション]-[再起動]→「同期中」となったら作業を進める。念のため以下でも確認。

SHOW VARIABLES LIKE 'binlog_format';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| binlog_format | MIXED |
+---------------+-------+

2)ブルー/グリーンデプロイ設定前にBlue側でバイナリログを発生させておく

Green環境の作成前に、Blue環境で何かしらの書き込み処理を行わなければ、下記のエラーが発生する。

Read Replica Replication Error - IOError: 1236, reason: Got fatal error 1236 from master when reading data from binary log: 'Could not find first log file name in binary log index file'

既知の問題として、バイナリログの出力を有効にしたのち、Green環境作成前にBlue側のデータベースに対して何かしらの書き込み処理を行う必要があるとのこと。
（参照：https://tech.connehito.com/entry/2023/01/10/181131）

show master status;
+----------------------------+----------+--------------+------------------+-------------------+
| File                       | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+----------------------------+----------+--------------+------------------+-------------------+
| mysql-bin-changelog.000003 |      120 |              |                  |                   |
+----------------------------+----------+--------------+------------------+-------------------+

Insertなどを行い、show master statusでPositionが増えていることを確認する。

■ブルー/グリーンデプロイの設定

ここまでできたら、クラスタを選択してB/Gデプロイの設定を進める
[アクション▲]-[ブルー/グリーンデプロイの作成-新規]

ブルーデータベース識別子
（規定値）

ブルー/グリーンデプロイ識別子
stg-hogehogeなど。一時的な識別子なのでなんかわかるようにつける

ブルー/グリーンデプロイ設定
・グリーンデータベースのエンジンバージョン：5.7.mysql.aurora-mysql5.7（推奨/最新）
→今回バージョンアップが目的だったのでこれでいく
・グリーンデータベースの DB クラスターパラメータグループ：あらかじめ用意しておいたクラスタ用パラメータグループ
・グリーンデータベースの DB パラメータグループ：あらかじめ用意しておいたパラメータグループ

上記設定したら
[ステージング環境の作成]
を実施

ブルー/グリーンデプロイ設定ができたらGreen側のバージョンを確認
– エンジンバージョン： 5.7.mysql_aurora.2.11.1（今回の最新となっている）
– DB クラスターのパラメータグループ： [再起動を保留中]となっているため再起動を実施する。
※Green側再起動後のタイミングでもBlueからのレプリケーションが行えていることを念の為確認。OK。

■切り替え

ロール：ブルー/グリーンデプロイ を選択し[アクション]-[切り替え]
→4分ほどで終了
Blueのエンドポイントで接続し、バージョン確認

select @@aurora_version;
+------------------+
| @@aurora_version |
+------------------+
| 2.11.1           |
+------------------+

→スイッチオーバー中にエンドポイント名が変わる
Green環境のエンドポイント名がBlueのものに変更され、旧Blue環境は「-oldn」付きに変更される

■後片付け

切り替えが終わっても旧インスタンスは稼働しているので削除する。
併せてブルー/グリーンデプロイも削除する。
「ブルー/グリーンデプロイを削除しても、ブルー環境に影響はありません。」
（https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/blue-green-deployments-deleting.html）
– ロール：ブルー/グリーンデプロイ を削除
– 旧ｄｂ(-oldn）クラスタを削除

■参照サイト

https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/blue-green-deployments-overview.html
https://tech.connehito.com/entry/2023/01/10/181131
https://speakerdeck.com/hmatsu47/green-depuroiwoshi-sitemita
https://dev.classmethod.jp/articles/enable-aurora-binary-logs/
https://dev.classmethod.jp/articles/rds-bg-deploy/
https://qiita.com/hmatsu47/items/cb69c0a4f0042b7666e7
https://www.sunnycloud.jp/column/20221229-01/

いつもながら元気玉ブログですみません。