Chapter 02

重要なポイント

hmatsu47
hmatsu47
2022.10.28に更新

この章について

全体の流れについて説明していく前に、移行を振り返って「ここが重要だった」と言えるポイントを先に挙げて説明します。

事前調査・確認を行う

Aurora MySQL v3 のベースである MySQL 8.0 は 5.7 以前のバージョンに対して、多くの非互換があります。

「MySQL 以外の RDBMS でも動く」「データ量が少ない」といったケースであれば別ですが、MySQL 5.7 以前での動作が前提となっているアプリケーションの場合は高確率で非互換の影響を受けるはずです。

MySQL Connector(接続ライブラリ)のバージョンを統一し、事前に動作確認・テストを行う

Oracle 提供の本家 MySQL 用 Connector は、対象言語によって差はあるものの、サーバーのマイナーバージョンごとの機能変更に合わせて仕様・挙動が変わります。

詳細はリリースノートを確認すると良いのですが、中にはリリースノートに記されていない変更もあります。

特に、ここ最近のマイナーバージョンでは日付・日時絡みの処理を中心に細かい仕様変更が入っているようです。

トラブルを避けるため、MySQL Connector の使用バージョン(マイナーバージョン)は全てのアプリケーションで合わせた上で、必ず動作確認・テストを通しておきます。

できれば、サーバーのバージョンアップ前に MySQL Connector に関する対応(非互換の確認・修正など)を済ませておくと良いでしょう。

移行作業についてひととおり事前検証とリハーサルを実施する

インプレースアップグレードで移行する場合、v1 → v2、v2 → v3 の 2 段階で進めることになりますが、何度か試してアップグレードの手順と所要時間を確認しておきます。

特に同時に多数のクラスタ・インスタンスをアップグレードしようとすると思いのほか時間が掛かることがあります。

また、対象システムのサービス停止時間を短縮したい場合はレプリケーションを併用することになりますが、DMS(CDC)レプリケーションが使えるのか(非推奨ですが)binlog レプリケーションする必要があるのか、事前に実験しておかないと移行本番でデータ不整合などのトラブルが生じる恐れがあります。

もちろん、データ整合確認方法も事前に決めて、できるだけ本番またはそれに近いデータを使って試しておく必要があります。

性能試験・負荷試験を行う

実際に移行してみるとわかるのですが、同じワークロードを実行したときの CPU 使用率や、高負荷時の挙動などの特性が過去のバージョンとやや異なる印象です。

性能に余裕がある状態で移行するのなら良いですが、移行前に CPU 使用率のピークが 60 〜 70% を超えている場合は特に、性能試験・負荷試験が必要です。