# Aurora MySQL DB クラスターのマイナーバージョンまたはパッチレベルのアップグレード
DB クラスターのマイナーバージョンをアップグレードしたり、DB クラスターにパッチを適用したりするには、次の方法を使用できます。
+ [エンジンのバージョンを変更して Aurora MySQL アップグレードする](AuroraMySQL.Updates.Patching.ModifyEngineVersion.md) (Aurora MySQL バージョン 2 および 3)
+ [Aurora MySQL マイナーバージョン間の自動アップグレードの有効化](AuroraMySQL.Updates.AMVU.md)
ダウンタイムなしのパッチ適用によってアップグレードプロセス中の中断を減らす方法については、「[ダウンタイムのないパッチ適用の使用](AuroraMySQL.Updates.ZDP.md)」を参照してください。
Aurora MySQL DB クラスターのマイナーバージョンアップグレードの実行については、以下のトピックを参照してください。
**Topics**
+ [マイナーバージョンアップグレードを実行する前に](#USER_UpgradeDBInstance.PostgreSQL.BeforeMinor)
+ [Aurora MySQL のマイナーバージョンアップグレードの事前チェック](#AuroraMySQL.minor-upgrade-prechecks)
+ [エンジンのバージョンを変更して Aurora MySQL アップグレードする](AuroraMySQL.Updates.Patching.ModifyEngineVersion.md)
+ [Aurora MySQL マイナーバージョン間の自動アップグレードの有効化](AuroraMySQL.Updates.AMVU.md)
+ [ダウンタイムのないパッチ適用の使用](AuroraMySQL.Updates.ZDP.md)
+ [代替のブルー/グリーンのアップグレードテクニック](#AuroraMySQL.UpgradingMinor.BlueGreen)
## マイナーバージョンアップグレードを実行する前に
マイナーバージョンのアップグレード中のダウンタイムを低減するには、次のアクションを実行することをお勧めします。
+ Aurora DB クラスターのメンテナンスは、トラフィックが少ない時間帯に実行する必要があります。メンテナンスウィンドウを適切に設定するには、Performance Insights を使用してこのような時間帯を特定します。Performance Insights については、「[Amazon RDS での Performance Insights を使用した DB 負荷のモニタリング](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PerfInsights.html)」を参照してください。DB クラスターのメンテナンスウィンドウの詳細については、「[DB クラスターの適切なメンテナンスウィンドウの調整](USER_UpgradeDBInstance.Maintenance.md#AdjustingTheMaintenanceWindow.Aurora)」を参照してください。
+ エクスポネンシャルバックオフとジッターをサポートする AWS SDK を使用することが、ベストプラクティスです。詳細については、 ブログ投稿、「[エクスポネンシャルバックオフとジッター](https://aws.amazon.com/blogs/architecture/exponential-backoff-and-jitter/)」を参照してください。
## Aurora MySQL のマイナーバージョンアップグレードの事前チェック
マイナーバージョンアップグレードを開始すると、Amazon Aurora は自動的に事前チェックを実行します。
これらの事前確認は必須です。スキップすることはできません。事前チェックには次の利点があります。
+ アップグレード中の計画外のダウンタイムを回避することができます。
+ 非互換性がある場合、Amazon Aurora でアップグレードすることはできません。詳細を示すログが出力されます。ログを使用して、非互換性を排除することにより、データベースをアップグレードする準備を行うことができます。非互換性の排除の詳細については、MySQL ドキュメントの「[アップグレードのためのインストールの準備](https://dev.mysql.com/doc/refman/8.0/en/upgrade-prerequisites.html)」を参照してください。
DB インスタンスがアップグレードで停止される前に事前チェックが実行されます。つまり、実行時にダウンタイムが発生することはありません。事前チェックで非互換性が見つかった場合、DB インスタンスが停止する前に、Aurora により自動的にアップグレードがキャンセルされます。Aurora では、非互換性のためのイベントも生成されます。Amazon Aurora イベントの詳細については、「[Amazon RDS イベント通知の操作](USER_Events.md)」を参照してください。
Aurora は、ログファイル `PrePatchCompatibility.log` に各非互換性に関する詳細情報を記録します。ほとんどの場合、ログエントリには非互換性を修正するための MySQL のドキュメントへのリンクが含まれています。ログの表示の詳細については、「[データベースログファイルの表示とリスト化](USER_LogAccess.Procedural.Viewing.md)」を参照してください。
事前チェックの性質上、データベース内のオブジェクトが分析されます。この分析によりリソースが消費され、アップグレードが完了するまでの時間が長くなります。
## 代替のブルー/グリーンのアップグレードテクニック
状況によっては、古いクラスターからアップグレードされたクラスターへの即時の切り替えが最優先事項です。このような場合、古いクラスターと新しいクラスターを並べて実行するマルチステッププロセスを使用できます。ここでは、新しいクラスターが引き継ぐ準備ができるまで、古いクラスターから新しいクラスターにデータをレプリケートします。詳細については、[データベース更新のために Amazon Aurora ブルー/グリーンデプロイを使用する](blue-green-deployments.md) を参照してください