Aurora MySQL DB クラスターのマイナーバージョンまたはパッチレベルのアップグレード
DB クラスターのマイナーバージョンをアップグレードしたり、DB クラスターにパッチを適用したりするには、次の方法を使用できます。
-
エンジンのバージョンを変更して Aurora MySQL アップグレードする (Aurora MySQL バージョン 2 および 3)
ダウンタイムなしのパッチ適用によってアップグレードプロセス中の中断を減らす方法については、「ダウンタイムのないパッチ適用の使用」を参照してください。
Aurora MySQL DB クラスターのマイナーバージョンアップグレードの実行については、以下のトピックを参照してください。
トピック
マイナーバージョンアップグレードを実行する前に
マイナーバージョンのアップグレード中のダウンタイムを低減するには、次のアクションを実行することをお勧めします。
Aurora DB クラスターのメンテナンスは、トラフィックが少ない時間帯に実行する必要があります。メンテナンスウィンドウを適切に設定するには、Performance Insights を使用してこのような時間帯を特定します。Performance Insights については、「Amazon RDS での Performance Insights を使用した DB 負荷のモニタリング」を参照してください。DB クラスターのメンテナンスウィンドウの詳細については、「DB クラスターの適切なメンテナンスウィンドウの調整」を参照してください。
-
エクスポネンシャルバックオフとジッターをサポートする AWS SDK を使用することが、ベストプラクティスです。詳細については、 ブログ投稿、「エクスポネンシャルバックオフとジッター
」を参照してください。
Aurora MySQL のマイナーバージョンアップグレードの事前チェック
マイナーバージョンアップグレードを開始すると、Amazon Aurora は自動的に事前チェックを実行します。
これらの事前確認は必須です。スキップすることはできません。事前チェックには次の利点があります。
-
アップグレード中の計画外のダウンタイムを回避することができます。
-
非互換性がある場合、Amazon Aurora でアップグレードすることはできません。詳細を示すログが出力されます。ログを使用して、非互換性を排除することにより、データベースをアップグレードする準備を行うことができます。非互換性の排除の詳細については、MySQL ドキュメントの「アップグレードのためのインストールの準備
」を参照してください。
DB インスタンスがアップグレードで停止される前に事前チェックが実行されます。つまり、実行時にダウンタイムが発生することはありません。事前チェックで非互換性が見つかった場合、DB インスタンスが停止する前に、Aurora により自動的にアップグレードがキャンセルされます。Aurora では、非互換性のためのイベントも生成されます。Amazon Aurora イベントの詳細については、「Amazon RDS イベント通知の操作」を参照してください。
Aurora は、ログファイル PrePatchCompatibility.log
に各非互換性に関する詳細情報を記録します。ほとんどの場合、ログエントリには非互換性を修正するための MySQL のドキュメントへのリンクが含まれています。ログの表示の詳細については、「データベースログファイルの表示とリスト化」を参照してください。
事前チェックの性質上、データベース内のオブジェクトが分析されます。この分析によりリソースが消費され、アップグレードが完了するまでの時間が長くなります。
代替のブルー/グリーンのアップグレードテクニック
状況によっては、古いクラスターからアップグレードされたクラスターへの即時の切り替えが最優先事項です。このような場合、古いクラスターと新しいクラスターを並べて実行するマルチステッププロセスを使用できます。ここでは、新しいクラスターが引き継ぐ準備ができるまで、古いクラスターから新しいクラスターにデータをレプリケートします。詳細については、「データベース更新のために Amazon RDS ブルー/グリーンデプロイを使用する」を参照してください。