2月末に↓の通知を受けて戦々恐々となった現場は結構あるのではないかと思っています。

RDS Security notification (Feb. 21)

（画像はこちら）

Links

[1] https://docs.aws.amazon.com/AmazonRDS/latest/AuroraMySQLReleaseNotes/AuroraMySQL.Updates.2110.html
[2] https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Updates.MajorVersionUpgrade.html#AuroraMySQL.Upgrading.Procedure
[3] https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-restore-snapshot.html
[4] https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/blue-green-deployments.html
[5] https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Updates.Upgrading.html
[6] https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Updates.html
[7] https://repost.aws/
[8] https://aws.amazon.com/support

本記事は、１ヶ月程の間にこれを乗り越えるために Amazon RDS ブルー/グリーンデプロイの利用を採用し、計画メンテナンスを実施していく^[1] 過程でわかったことなどをご紹介する記事です。
誰かの何かのお役に立てば幸いです。
(4/3まではあと２週間ほどあります・・・)

やらなければならないこと

4/3 以降、Aurora MySQL 2.10 (MySQL 5.7 互換) が廃止となる前に、アップグレードを行うことが必要。やっておかないと、強制アップグレードが発動し、再起動が走る。その間、サービスがダウンすることになる。

このサービスダウンを回避するための選択肢は大別すると２つで、

「表側」をメンテナンス表示にしてその裏でアップグレードする
- この場合のダウンタイムはだいたい30分程度（自分が検証で計測した体感）
Amazon RDS ブルー/グリーンデプロイ（以下「B/Gデプロイ」）でアップグレードする
- これを利用した場合のダウンタイムはだいたい1分程度（近くの経験者の実施談）

より少ない損失で済ませたいのであれば選択するのはどちらか？は自明で、2番目を選択して進めました。（一部、許容されるとのことで 1.を選択したものもありました。1.でもなくメンテナンス入れないという「ダウンすることを選択する」も考え方によってはありえます）

だがしかし

binlog_format

B/Gデプロイに必要な条件として、クラスターパラメータグループの binlog_format が有効となってないと、です。

いくつかなってなかったプロダクトがあったりしたので、メンテナンス実施の２日前に以下を行いました。

該当クラスターのパラメータグループを調整しておく
その上でリーダーインスタンスを追加（※フェールオーバー優先順位を tier-0 に）
(データの整合性を壊さないために必要に応じてアプリケーションをメンテナンスモードに)
フェールオーバーする（停止時間はマネコン見ていた感じでは1分程度）
(メンテナンスモードを解除)
binlog_format が有効となっていることを確認
- SHOW variables LIKE "binlog_format"

作成中から進まない

これがこの記事で伝えたいことで、アクションから「ブルー/グリーンデプロイの作成・新規」に進んで「ステージング環境の作成」を始めてから 10分経過して Green が発生してなかったら 、 ~~基盤側に何らかの問題があって~~ ^[2] ダメなので、AWS サポートに連絡して以下を知らせて「制限解除」してもらう必要がありました。

1. 対象の DB クラスターの ARN
2. Blue Green Deployment をご利用されたい背景、詳細
3. エンジンバージョンアップグレードを完了させる予定日

申請して、「Blue Green Deployment を作成可能とする例外申請が承認され」ないと、いくらTryしても同じ結果になります。しかしメンテナンスの日は刻一刻と迫る・・・

切り替え前の要確認事項

なんとか主要なプロダクトは Green ができてきてくれて、事前に Aurora MySQL 2.11.1 (MySQL 5.7 互換) や Aurora MySQL 3.03.0 (MySQL 8.0 互換) に上げておいたり、パフォーマンスインサイトを有効にしたり、といった準備ができました。

あとはそれに切り替えるのが無事に終われば、というところなので、切り替える前の確認事項として実践したことを記載します。

REPLICA STATUS

チェックしたのは以下

Slave_IO_State:
- Waiting for source to send event もしくは Queueing master event to the relay log
Last_Errno:
- 0
Last_Error:
- (空)
Slave_SQL_Running_State:
- Replica has read all relay log; waiting for more updates もしくは Reading event from the relay log

最新データが入っているか

「こんな感じ」というSQL例です。要は書き込みが頻繁なテーブルに最新データがあるか、のチェック。
これを、ライター・リーダー両方を見ておきました。（一致しないことも考えられるのでそのあたりは各現場でご判断ください）

SELECT id, created_at FROM frequently_write_table ORDER BY id DESC LIMIT 10;

切り替えが失敗した場合

基本ではあるのですが、ログをまず見ましょう。
そして、blue のクラスターに binlog レプリケーションが張られてたりしないかを、SHOW PROCESSLIST; を確認して見直すと、打開策が見えるかもしれません。
対処に使用したコマンドのリファレンスを置いておきます。

AWS > ドキュメント > Amazon Relational Database Service (RDS) > ユーザーガイドより

なお、AWS サポートに問合せして教えてもらったのですが、 切り替えガードレール というのがあるようで、以下ドキュメントに説明があります。

切り替え後の後始末

古いほう（切り替え前のBlue）の削除

💸 の問題もあるので、無事に切り替えが完了したら古いほうは削除したくなるのが自分なのですが、

いつ削除するのか
スナップショットを取っておくのか

は事前に決めておいた方が良さそうです。
それと、削除するにはクラスターの削除保護を解除する必要があります。

B/Gデプロイのオブジェクト(?)は切り替え完了すれば削除してOKと思うのですが、自分の場合謎のエラーが出ました。

謎のエラー

（画像はこちら）

リロードしたら何もない状況となったのでスルーしました。

その他

B/Gデプロイ先のクラスター名は60文字以内

検証用・・・と思って日付入れたりしたら超えちゃいました

（画像はこちら）

以降、クラスター名の末尾に -bg を付けるだけ、にしましたw。

テーブル名が MySQL 8 では予約語というケース

追加されたバージョン: 8.0 : 116
予約になったバージョン: 8.0 : 4

あります。動作確認していたら今まで動いていたところが動かなくなっていて、追跡したところコレでした。。
Aurora MySQL 2.11.1 へのアップグレードに今回はとどめました。

勤怠どうつけるんですか？問題

自分は業務委託なのであまり関係ないんですが、未明の作業になった（サービストラフィックが最も少ない時間曜日を選んでこうなった）ので、「勤怠どうするんですか？」に弊現場は困ったようです。そういえばひっさしぶりの未明メンテ。自宅からのリモートでやったのは初めてかも。昔は集まってやってましたね。

最近随所でメンテナンスって聞いてるんですが

これの割合が高いんじゃないかなあ、と思ってます（個人の見解です）

脚注

実はメンテナンス作業で予期せぬB/Gデプロイ切り替え失敗となり、リトライ計画を検討開始している。-> リトライ成功しました。 ↩︎
2023/3/22 15:30 時点の情報ではこの問題はFixされたと伺っています。 ↩︎

Discussion