Amazon Aurora MySQL v1（5.6 互換）→ v3（8.0 互換）移行を計画する（3）AWS 公式ドキュメントを読む（1）

これは

• Amazon Aurora MySQL v1（5.6 互換）→ v3（8.0 互換）移行を計画する（2）調査の進め方と参考資料

の続きです。

今回は AWS 公式の Aurora 関連ドキュメントのうち、クラスタの移行に関する部分を取り上げてみます。

「Aurora MySQL DB クラスターのメジャーバージョンのアップグレード」を読む

https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Updates.MajorVersionUpgrade.html

より、重要な情報を拾っていきます。

2022/2/25 時点で公開されている情報をもとに書いています。

• Aurora MySQL v1 から直接 v3 へはアップグレードできない
• Aurora MySQL v1 → v2 はインプレースアップグレードできるが、処理時間が掛かる
  • 特に v1.22.3 より前のバージョンからアップグレードする場合
• クローン・スナップショットからの復元や、binlog レプリケーションを組み合わせた Blue/Green デプロイも使える
• Aurora MySQL v2 → v3 はクローン・インプレースアップグレードできない
  • スナップショットからの復元でアップグレードする

2022/9/29 追記：
Aurora MySQL v2 → v3 の インプレースアップグレードがサポートされました。

2023/1/21 追記：
スナップショットからの復元時のアップグレードやインプレースアップグレードの際に、ストアドプロシージャやストアドファンクションでクォートのない 予約語 をテーブル名・列名などに使うと途中で失敗します。
ご注意ください。

• v1 → v2 の際にengine属性がauroraからaurora-mysqlに変わる
  • CLI や API で処理を自動化している場合に注意
• パラメータグループに注意
  • デフォルトとは別のパラメータグループを使っている場合や、CLI・API で処理を自動化している場合は特に注意

2022/2/27 追記：
CLI を使った具体的なアップグレード操作については取り上げていませんが、以下のリンク先に例示があります。

• Aurora MySQL インプレースアップグレードのチュートリアル
• Aurora MySQL バージョン 1 からバージョン 3 へのアップグレードの例

Aurora MySQL v1 から直接 v3 へはアップグレードできない

一旦 v2 に移行してから v3 に移行しましょう、という話です。

スナップショットからの復元でも、v1 から v3 に直接アップグレードはできないようです。

Aurora MySQL v1 → v2 はインプレースアップグレードできるが、処理時間が掛かる

インプレースアップグレードは同一リージョンで同時に処理できる数に限りがありそうです。以前、どこかの AWS ユーザさんが複数のクラスタを同時にアップグレードしようとして計画時間内に全然進まなかったという話をされていました。

移行作業は特定のメンテナンス日に一気に行うのではなく、可能なら binlog レプリケーションを併用して段階的に準備を進める方法を取るのが良さそうです。

なお、v1.22.3 より前のバージョンからアップグレードする場合は、内部的に 2 段階のアップグレードになるため特に時間が掛かるようです。

クローン・スナップショットからの復元や、レプリケーションを組み合わせた Blue/Green デプロイも使える

こちらのブログ記事が紹介されています。

https://aws.amazon.com/jp/blogs/database/performing-major-version-upgrades-for-amazon-aurora-mysql-with-minimum-downtime/

v3 が GA になる前の記事なので v3 アップグレードへの言及はありません。

クローン後に差分を binlog レプリケーションして Green 環境を構築する話が出ていますが、v1 → v3 に応用するなら、

1. 一旦 v1 → v2 をクローンまたはスナップショットからの復元で実行
2. v2 のスナップショットを取って v3 指定で復元
3. v1 → v3 レプリケーションでデータの差分を反映して Green 環境を構築
4. 動作確認した後 Blue 環境に昇格
5. 後始末

となるでしょうか。

ただし MySQL 5.6 から 8.0 への binlog レプリケーションは非推奨なので、安全に進めるなら v1 → v2 のアップグレードを Blue/Green 方式で実施した後で、あらためて別日程で v2 → v3 のアップグレードを実施すれば良いでしょう。

以前の MySQL でよく行われていた 3 つ（以上）のバージョンをまたぐ多段レプリケーションも、現在の MySQL では非推奨となっています。

この記事では binlog 形式としてMIXED形式を推奨していますが、ROW形式でも大丈夫だと思います。

ROW形式との比較で、MIXED形式のほうが、

• 容量を節約できる
• 何か問題が生じた場合に原因となった SQL 文を突き止めやすい

などのメリットがあります。ただし MySQL 8.0 のデフォルトはROW形式です。
また、データ移行やレプリケーションに DMS（Database Migration Service）を使いたい場合はROW形式を使います。

2022/12/22 追記：
フルマネージドの Blue/Green デプロイがサポートされました。
こちらは 1 バージョンずつ上げていく場合に使えるものです（一度のスイッチオーバーで v1 → v3 に上げることはできません）。
https://qiita.com/hmatsu47/items/cb69c0a4f0042b7666e7
https://qiita.com/hmatsu47/items/922c4f23a1e66f948947
https://qiita.com/hmatsu47/items/9a5afb73d2774600fdd9
なお binlog はMIXED形式のみサポートしているようです。

2022/12/29 追記：
スナップショットからの復元やインプレースアップグレードは予想外に長時間かかる可能性があります（筆者もそのような事態に遭遇したことがあります）。
できればレプリケーションによる Blue/Green デプロイを利用することで、移行時のメンテナンス停止時間が不意に延びてしまうのを避けたいところです。

Aurora MySQL v2 → v3 はクローン・インプレースアップグレードできない

今後クローン・インプレースアップグレード対応になる可能性はありますが、現時点ではスナップショットからの復元でアップグレードすることになります。

2022/9/29 追記：
前述のとおり、Aurora MySQL v2 → v3 の インプレースアップグレードがサポートされました。

この関係で、グローバルデータベース構成にしている場合は v3 に移行する難易度が高いと思います（できなくはないと思いますが）。

クラスタ数やインスタンス数が多い場合も厳しそうですね（並行して新旧バージョンのクラスタを用意する場合はクォータに引っ掛かりそうなので上限緩和申請が必要かもしれません）。

v1 → v2 の際にengine属性がauroraからaurora-mysqlに変わる

マネジメントコンソールだけ使っている場合には関係ないのですが、CLI や SDK などを使って API を呼び出すコードを書いている場合、パラメータとして指定する属性（engine）が変わるので修正が必要になります。

パラメータグループに注意

Aurora MySQL v1 と v2、v3 でクラスタとデータベースのパラメータグループが違います。

カスタムパラメータグループを使っている場合は、アップグレード前にあらかじめ v3 用のカスタムパラメータグループを作っておきます。

CLI や SDK などを使って API を呼び出すコードを書いている場合、パラメータ指定も変える必要があります。

なお、ここではまだ詳細には触れませんが MySQL 5.6 と 8.0 ではサーバのパラメータにかなり違いがあり、Aurora のパラメータグループの項目や初期値も違います。さらに同じパラメータ名のengine-defaultが指す値が v1 と v3 で異なるケースなど、パラメータグループの差分が表示されなくても値の書き換えが必要な場合があります。

まとめ

• Aurora MySQL v1 から v3 には直接移行できない
• そのため、グローバルデータベースや多クラスタ環境では一旦 v2 までのアップグレードに止めたほうが良さそう
• アップグレードには時間が掛かるのでレプリケーションを利用した Blue/Green 方式の移行を検討したほうが良い
• インフラの自動化・コード化を実装している場合はパラメータとして指定する属性値の修正が必要になる
• Aurora MySQL v1・v2・v3 の間でパラメータグループの項目や初期値、デフォルト値が違うので移行時に差分の確認が必要

レプリケーションを使って移行する場合、DMS の使用を検討したほうが良いかもしれません。その場合、binlog はROW形式を使います。

• https://docs.aws.amazon.com/ja_jp/dms/latest/userguide/Welcome.html
• https://docs.aws.amazon.com/ja_jp/dms/latest/userguide/CHAP_Source.MySQL.html
• https://docs.aws.amazon.com/ja_jp/dms/latest/userguide/CHAP_Target.MySQL.html

2022/9/29 追記：
ただし、↓ こちらの記事のような問題が発生するケースでは、DMS（CDC）を使ったレプリケーションが使えないので注意が必要です。

• https://zenn.dev/hmatsu47/articles/mysql-dms-cdc-timestamp-mismatch

---

• Amazon Aurora MySQL v1（5.6 互換）→ v3（8.0 互換）移行を計画する（4）AWS 公式ドキュメントを読む（2）

に続きます。