背景
先日、Amazon Aurora MySQL version 1 ( MySQL 5.6 互換 ) のEOLが2023/02/28に予定されました ( 以降、Aurora MySQL v1と記述 )。 2022/09/27 からAurora MySQL v1の作成ができなくなります。 Aurora MySQL v1で動作しているクラスターをAurora MySQL v2 ( MySQL 5.7 互換 ) or Aurora MySQL v3 ( MySQL8.0 互換 )にバージョンアップする必要があります。
アップグレードの方法
アップグレードの方法は主にインプレースアップグレードとBlue/Greenアップグレードの2種類の方法があります。
インプレースアップグレード
利用中のクラスタでアップグレード処理を実施します。インスタンスのシャットダウンが発生しますが手順はシンプルです。エンドポイントはそのまま保持されるため変更の手間もありません。
Blue/Greenアップグレード
aws.amazon.com (英語ドキュメントしか無さそう)
新しくMySQL5.7のクラスタを構築して、MySQL5.6のクラスタからデータをレプリケーションすることで2つのクラスタが同じデータを保持している状態を作ります。最終的にエンドポイントの切り替えによってバージョンアップを実施します。インプレースアップグレードよりもダウンタイムを少なくすることができます。
インプレースアップグレードを実施して分かった問題
インプレースアップグレードはとてもざっくりですが↓の図のような流れでアップグレード処理が走ります。
問題なのは↑の赤いPending Reboot (再起動保留中)
の状態で、再起動を待ちながらDBインスタンスは起動しています。
このPending Reboot (再起動保留中)
の状態ではデフォルトのパラメータグループ( default.aurora-mysql5.7
)でAurora が動作している状態です。そしてカスタムパラメータ設定を適用するには手動で再起動を実施する必要があります。
これはドキュメントにも下記のように書いてあります。
アップグレードプロセス中にカスタムパラメータグループを指定した場合は、アップグレード終了後にクラスターを手動で再起動する必要があります。再起動すると、クラスターがカスタムパラメータ設定の使用を開始できます。
つまりアプリケーションを起動した状態でインプレースアップグレードを実施した場合、カスタムパラメータグループの内容によってはサービス影響が発生する可能性があります。
対策
アップグレードの前後でアプリケーションを停止する
インプレースアップグレードの所要時間はデータ量やクラスターのビジー状態によって変わってくるのでアプリケーションの停止時間が読みにくいというところはあります。
Blue/Greenアップグレードを採用する
Blue/Greenアップグレードはクラスタを新しく構築するためエンドポイントを参照している箇所を変更する必要があります。参照している箇所が把握できていなかったり、変更箇所が多かったりすると結構大変な作業になりそうです。
まとめ
- 2023/02/28 に Aurora MySQL v1 が EOL を迎えます
- アップグレードの方法はインプレースアップグレードとBlue/Greenアップグレードの2種類
- カスタムパラメータを利用してインプレースアップグレードを行う場合には注意が必要