Chapter 07

調査(3)移行手順に関する情報

hmatsu47
hmatsu47
2022.09.29に更新

この章について

著者が v1 → v3 の変更点調査の中で見つけた移行手順に関する情報を記します。

移行手順に関する情報

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

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

v1 → v2 はクローン・インプレースアップグレードまたはスナップショット復元によるアップグレードを行います。

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

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

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

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

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

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

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 アップグレードへの言及はありません。

実際のところ MySQL 5.6 → 8.0 の binlog レプリケーションは非推奨(無保証)なので、Aurora MySQL でも v1 → v3 の binlog レプリケーションではなく、DMS(CDC)を使ったレプリケーションをお勧めします。

DMS レプリケーションであれば切り戻し方向のレプリケーションも可能です。

その他

移行手順そのものではありませんが、移行手順に関係がありそうな点を記します。

バックトラック未サポート

現時点ではバックトラックを使用中のクラスタで作成したスナップショットからの復元ができません。

今後のマイナーバージョンでサポート予定です。

Aurora Serverless v1 クラスタ非サポート

2022/04/21 GA の Aurora Serverless v2 クラスタでサポートされています(バージョン 3.02.0 以降)。

mysql.lambda_asyncストアドプロシージャ削除

非同期関数lambda_asyncで代替します。