Aurora MySQL DB クラスターのマイナーバージョンまたはパッチレベルのアップグレード - Amazon Aurora

Aurora MySQL DB クラスターのマイナーバージョンまたはパッチレベルのアップグレード

DB クラスターのマイナーバージョンをアップグレードしたり、DB クラスターにパッチを適用したりするには、次の方法を使用できます。

ダウンタイムなしのパッチ適用によってアップグレードプロセス中の中断を減らす方法については、「ダウンタイムのないパッチ適用の使用」を参照してください。

Aurora MySQL DB クラスターのマイナーバージョンアップグレードの実行については、以下のトピックを参照してください。

マイナーバージョンアップグレードを実行する前に

マイナーバージョンのアップグレード中のダウンタイムを低減するには、次のアクションを実行することをお勧めします。

Aurora MySQL のマイナーバージョンアップグレードの事前チェック

マイナーバージョンアップグレードを開始すると、Amazon Aurora は自動的に事前チェックを実行します。

これらの事前確認は必須です。スキップすることはできません。事前チェックには次の利点があります。

  • アップグレード中の計画外のダウンタイムを回避することができます。

  • 非互換性がある場合、Amazon Aurora でアップグレードすることはできません。詳細を示すログが出力されます。ログを使用して、非互換性を排除することにより、データベースをアップグレードする準備を行うことができます。非互換性の排除の詳細については、MySQL ドキュメントの「アップグレードのためのインストールの準備」を参照してください。

DB インスタンスがアップグレードで停止される前に事前チェックが実行されます。つまり、実行時にダウンタイムが発生することはありません。事前チェックで非互換性が見つかった場合、DB インスタンスが停止する前に、Aurora により自動的にアップグレードがキャンセルされます。Aurora では、非互換性のためのイベントも生成されます。Amazon Aurora イベントの詳細については、「Amazon RDS イベント通知の操作」を参照してください。

Aurora は、ログファイル PrePatchCompatibility.log に各非互換性に関する詳細情報を記録します。ほとんどの場合、ログエントリには非互換性を修正するための MySQL のドキュメントへのリンクが含まれています。ログの表示の詳細については、「データベースログファイルの表示とリスト化」を参照してください。

事前チェックの性質上、データベース内のオブジェクトが分析されます。この分析によりリソースが消費され、アップグレードが完了するまでの時間が長くなります。

代替のブルー/グリーンのアップグレードテクニック

状況によっては、古いクラスターからアップグレードされたクラスターへの即時の切り替えが最優先事項です。このような場合、古いクラスターと新しいクラスターを並べて実行するマルチステッププロセスを使用できます。ここでは、新しいクラスターが引き継ぐ準備ができるまで、古いクラスターから新しいクラスターにデータをレプリケートします。詳細については、「データベース更新のために Amazon RDS ブルー/グリーンデプロイを使用する」を参照してください。