Zenn
📘

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

2022/02/25に公開
AWS
MySQL
aurora
#
バージョンアップ
#
移行
tech

これは

の続きです。

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

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

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

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

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 のアップグレードを実施すれば良いでしょう。

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

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 の間でパラメータグループの項目や初期値、デフォルト値が違うので移行時に差分の確認が必要

に続きます。

GitHubで編集を提案

Discussion