RDS B/G Deployments機能でAuroraクラスターバージョンアップした後の切り戻しを考える

最初にまとめ

• Blue/Green Deploymentsでバージョンアップしてもなんとか切り戻せる方法はある
• 今回の検証では3パターン中2つはうまく切り戻せた

• どの切り戻し方法にせよDBの書き込みを停止するサービスメンテナンスは必須

• バージョン切り戻しより新バージョンで対応できるよう修正したほうが現実的

Blue/Green Deploymentsによるバージョンアップ

切り戻しパターンを3つ検証

• Green(MySQL8.0)からBlue(MySQL5.7)への逆方向のレプリケーションする方法

• Green(MySQL8.0)から論理バックアップを取得して、Blue(MySQL5.7)に適用する方法

• Green(MySQL8.0)の静止点から差分をbinlogから生成して、Blue(MySQL5.7)に適用する方法

検証用環境の作成

• Auora Version2系のクラスタ作成

• 検証用のテーブル作成とレコード追加
• データーベース&テーブル作成
• レコード追加

• Blue/Green Deployments機能でGreen(MySQL8.0)クラスタの作成

• Green(MySQL8.0)とBlue(MySQL5.7)のクラスタ両方でbinlog保持期間を7日まで伸ばしておく

Green(MySQL8.0)からBlue(MySQL5.7)への逆方向のレプリケーションする方法

概要

検証手順

• サービスメンテナンスモードなどにしてDB書き込みを停止

• B/G切替実行

• B/Gロールの削除

• Green(MySQL8.0)でポジション確認

• Green(MySQL8.0)でレプリユーザーの作成

• 旧Blue(MySQL5.7)でGreen(MySQL8.0)に向けてレプリケーションの開始

• 旧blue(MySQL5.7)でレプリケーションの状態確認

• Green(MySQL8.0)で動作確認用のレコード追加

• 旧blue(MySQL5.7)でレプリケーションの状態確認

• 旧blue(MySQL5.7)でレコードをみてレプリケーションが正常に行われていることを確認

• サービスメンテナンスモードを解除してDBの書き込みを再開

Green(MySQL8.0)から論理バックアップを取得して、Blue(MySQL5.7)に適用する方法

概要

検証手順

• B/G切替実行

• B/Gロールの削除

• 切替後、Green(MySQL8.0)にレコード追加テスト

• サービスメンテナンスモードなどにしてDB書き込みを停止

• Green(MySQL8.0)でmysqldumpを実行
注意点1
💡
Auroraでは管理ユーザでもSUPER権限をもっていないため、-all-databasesオプションを使用するとうまくダンプ・リストアができません。 バックアップとりたい個別のデータベースを指定するようにしましょう。
注意点2
オプションを利用する場合、下記のブロク記事にある点に注意しましょう。
【追記あり】MySQL8.0.32と5.7.41のmysql-clientだとAmazon RDS/Auroraに--single-transactionオプションつけたmysqldumpが実行できない - CyberAgent SRG #ca_srg
技術本部 サービスリライアビリティグループ（SRG）の鬼海（@fat47）です。 #SRG（Service Reliability Group）は、主に弊社メディアサービスのインフラ周りを横断的にサポートしており、既存サービスの改善や新規立ち上げ、OSS貢献などを行っているグループです。 本記事は、SRG 内にある D
https://ca-srg.dev/906820228f654a1a8148d50aa31e82f1

• 旧Blue(MySQL5.7)でリストア

• 旧Blue(MySQL5.7)のレコード内容確認。Green(MySQL8.0)に追加した内容が含まれていることが確認できました。

• Green(MySQL8.0)のインスタンスやクラスタを削除

• 旧Blue(MySQL5.7)のインスタンスやクラスタをリネームして、の表記を消す

• サービスメンテナンスモード解除でサービス再開

Green(MySQL8.0)の静止点から差分をbinlogから生成して、Blue(MySQL5.7)に適用する方法

概要

検証手順

• サービスメンテナンスモードなどでDB書き込みを停止

• B/G切替実行

• B/Gロールの削除

• Green(MySQL8.0)の現時点のポジション確認してメモる

• サービスメンテナンスが解除されたと想定していくつか更新クエリを実行

• 切り戻し実行のために再度サービスメンテナンスモードなどでDB書き込みを停止

• 書き込み停止後のGreenの現在のポジションを確認

• Greenのbinlogを取得(MySQL ClientがインストールされているOpe用サーバなどで操作)

• 上記スクリプトでope用サーバの/tmpにbinlogファイルが出力されている

• mysqlbinlogコマンドで復旧用のSQLファイルを生成する

• 旧Blue(MySQL5.7)のテーブルの状態確認
• もちろんINSERT3件は反映されていないのを確認

• 旧Blue(MySQL5.7)にrecovery.sqlを流し込むとSUPER権限が必要というエラーが発生

• エラー対象のrecovery.sqlの9行目はROWでの更新部分

• mysqlbinlogコマンドで復旧用のSQLファイルを生成するときにしても、クエリ部分がコメントアウトされてしまうのでリストアされない。
件数が少ない場合は、差分SQLの編集や置換でINSERTやUPDATEなどのコメントアウトを消せばいいが、本番環境での切り戻し利用には差分件数も多く、難しそう。

余談

• MySQL5.7のclientでAurora MySQL3系(MySQL8.0)のクラスタのbinlogを取得しようとするとエラーになります。

• MySQL8.0のClientで取得してきた、Aurora MySQL3系(MySQL8.0)のクラスタのbinlogをつかって、MySQL5.7のclientのmysqlbinlogで無理やりSQL生成しようとしてもエラーになります。

• Aurora Version2(MySQL5.7)へのリストア時にSUPER権限が求められたのは、今回の更新差分SQLファイルでは3箇所です。

• Aurora Version3(MySQL8.0)ではSUPER権限が非推奨となり、それぞれ必要な権限が変更になっています。

コマンド	必要な権限
BINLOG 'xxxxxxxxxx';	SUPER, BINLOG_ADMIN or REPLICATION_APPLIER
SET @@SESSION.GTID_NEXT='AUTOMATIC'	SUPER, SYSTEM_VARIABLES_ADMIN, SESSION_VARIABLES_ADMIN or REPLICATION_APPLIER
SET @@session.pseudo_thread_id=xxxxx/	SUPER, SYSTEM_VARIABLES_ADMIN or SESSION_VARIABLES_ADMIN

• Aurora Version3(MySQL8.0)のマスターユーザーがもっているデータベースロール に、が含まれているため、今回の差分修正SQLはAurora Version3(MySQL8.0)では問題なくリストアできます。

参考URL

終わりに