# 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)」を参照してください。
事前チェックの性質上、データベース内のオブジェクトが分析されます。この分析によりリソースが消費され、アップグレードが完了するまでの時間が長くなります。
# エンジンのバージョンを変更して Aurora MySQL アップグレードする
Aurora MySQL DB クラスターのマイナーバージョンをアップグレードすると、既存のクラスターに追加の修正と新しい機能が適用されます。
このようなアップグレードは、元のバージョンとアップグレード後のバージョンの両方が Aurora MySQL メジャーバージョン (バージョン 2 または パージョン 3) である Aurora MySQL クラスターに適用されます。このプロセスは、Aurora MySQL メタデータの変換やテーブルデータの再編成を必要としないため、迅速で単純明快です。
この種のアップグレードを実行するには、AWS マネジメントコンソール、AWS CLI、RDS API のいずれかを使用して DB クラスターのエンジンバージョンを変更します。例えば、クラスターで Aurora MySQL 3.x が実行されている場合は、より高い 3.x バージョンを選択します。
Aurora Global Database でマイナーアップグレードを実行する場合は、プライマリクラスターをアップグレードする前に、すべてのセカンダリクラスターをアップグレードします。
**注記**
Aurora MySQL バージョン 3.04.\$1 以上またはバージョン 2.12.\$1 へのマイナーバージョンアップグレードを実行するには、次のプロセスを使用します。
グローバルクラスターからすべてのセカンダリリージョンを削除します。「[Amazon Aurora Global Database からのクラスターの削除](aurora-global-database-detaching.md)」のステップを実行してください。
必要に応じて、プライマリリージョンのエンジンバージョンをバージョン 3.04.\$1 以上、またはバージョン 2.12.\$1 にアップグレードします。「[To modify the engine version of a DB cluster](#modify-db-cluster-engine-version)」のステップを実行してください。
グローバルクラスターにセカンダリリージョンを追加します。「[AWS リージョン の Amazon Aurora Global Database への追加](aurora-global-database-attaching.md)」のステップを実行してください。
**DB クラスターのエンジンバージョンを変更するには**
+ **コンソールを使用する場合** -クラスターのプロパティを変更します。[**DB クラスターの変更**] ウィンドウの [**DB エンジンバージョン**] ボックスで、Aurora MySQL エンジンバージョンを変更します。クラスターを変更するための一般的な手順に慣れていない場合は、「[コンソール、CLI、API を使用した DB クラスターの変更](Aurora.Modifying.md#Aurora.Modifying.Cluster)」の手順に従ってください。
+ **AWS CLI を使用する場合** - AWS CLI コマンドの [modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html) を呼び出し、DB クラスターの名前を `--db-cluster-identifier` オプションで指定しながら、エンジンバージョンを `--engine-version` オプションで指定します。
例えば、Aurora MySQL バージョン 3.04.1 にアップグレードするには、`--engine-version` オプションを `8.0.mysql_aurora.3.04.1` に設定します。DB クラスターのエンジンバージョンをすぐに更新するには、`--apply-immediately` オプションを指定します。
+ **RDS API を使用する場合** - [ModifyDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html) API オペレーションを呼び出し、`DBClusterIdentifier` で DB クラスターの名前を指定して `EngineVersion` パラメータでエンジンバージョンを指定します。DB クラスターのエンジンバージョンをすぐに更新するには、`ApplyImmediately` パラメータを `true` に設定します。
# Aurora MySQL マイナーバージョン間の自動アップグレードの有効化
Amazon Aurora MySQL DB クラスターの場合、Aurora で DB クラスターを自動的に新しいマイナーバージョンにアップグレードするように指定できます。そのためには、DB クラスターの `AutoMinorVersionUpgrade` プロパティ (AWS マネジメントコンソール の **[マイナーバージョン自動アップグレード**]) を設定します。
自動アップグレードはメンテナンスウィンドウ中に実行されます。DB クラスター内の個々の DB インスタンスのメンテナンスウィンドウがクラスターメンテナンスウィンドウと異なる場合は、クラスターメンテナンスウィンドウが優先されます。
マイナーバージョンの自動アップグレードは、次の種類の Aurora MySQL クラスターには適用されません。
+ Aurora グローバルデータベースの一部であるクラスター
+ クロスリージョンレプリカを持つクラスター
停止時間は、ワークロード、クラスターサイズ、バイナリログデータの量、および Aurora がゼロダウンタイムパッチ適用 (ZDP) 機能を使用できるかどうかによって異なります。Aurora はデータベースクラスターを再起動するため、クラスターの使用を再開する前に、可用性が短時間失われることがあります。特に、バイナリログデータの量が復旧時間に影響を与えます。DB インスタンスは、復旧中にバイナリログデータを処理します。したがって、バイナリログデータが大量である場合、復旧時間が長くなります。
**注記**
Aurora は、DB クラスター内のすべての DB インスタンスで `AutoMinorVersionUpgrade` 設定が有効になっている場合にのみ、自動アップグレードを実行します。設定方法、およびクラスターレベルとインスタンスレベルで適用した場合にどのように機能するかについては、「[Aurora DB クラスターのマイナーバージョン自動アップグレード](USER_UpgradeDBInstance.Maintenance.md#Aurora.Maintenance.AMVU)」を参照してください。
その後、`AutoUpgrade` が true に設定されているマイナー DB エンジンへの DB クラスターインスタンスのアップグレードパスが存在する場合、アップグレードが実行されます。`AutoUpgrade` 設定は動的で、RDS によって設定されます。
マイナーバージョンの自動アップグレードは、デフォルトのマイナーバージョンについて実行されます。
次のような CLI コマンドを使用すると、Aurora MySQL クラスター内のすべての DB インスタンスで `AutoMinorVersionUpgrade` 設定のステータスを確認できます。
```
aws rds describe-db-instances \
--query '*[].{DBClusterIdentifier:DBClusterIdentifier,DBInstanceIdentifier:DBInstanceIdentifier,AutoMinorVersionUpgrade:AutoMinorVersionUpgrade}'
```
このコマンドでは、次のような出力が生成されます。
```
[
{
"DBInstanceIdentifier": "db-t2-medium-instance",
"DBClusterIdentifier": "cluster-57-2020-06-03-6411",
"AutoMinorVersionUpgrade": true
},
{
"DBInstanceIdentifier": "db-t2-small-original-size",
"DBClusterIdentifier": "cluster-57-2020-06-03-6411",
"AutoMinorVersionUpgrade": false
},
{
"DBInstanceIdentifier": "instance-2020-05-01-2332",
"DBClusterIdentifier": "cluster-57-2020-05-01-4615",
"AutoMinorVersionUpgrade": true
},
... output omitted ...
```
この例では、DB クラスター `cluster-57-2020-06-03-6411` の **[マイナーバージョン自動アップグレードの有効化]** がオフになっています。これは、クラスター内の DB インスタンスの 1 つでオフになっているためです。
# ダウンタイムのないパッチ適用の使用
Aurora MySQL DB クラスターのアップグレードを実行する場合、データベースがシャットダウンされたときおよびアップグレード中に停止する可能性があります。デフォルトでは、データベースがビジー状態のときにアップグレードをスタートすると、DB クラスターが処理しているすべての接続とトランザクションが失われます。アップグレードを実行するためにデータベースがアイドル状態になるまで待機する場合は、長時間待機しなければならない場合があります。
ダウンタイムのないパッチ適用 (ZDP) 機能では、ベストエフォートに基づいて、Aurora MySQL アップグレード中のクライアント接続を維持するよう試みます。ZDP が正常に完了されると、アプリケーションのセッションが保持され、アップグレードの進行中にデータベースエンジンが再起動します。データベースエンジンの再起動により、数秒から約 1 分間スループットが低下する可能性があります。
ZDP は以下には適用されません。
+ オペレーティングシステム (OS) のパッチとアップグレード
+ メジャーバージョンのアップグレード
ZDP は、サポートされているすべての Aurora MySQL バージョンと DB インスタンスクラスで使用できます。
ZDP は Aurora Serverless v1 または Aurora グローバルデータベースではサポートされていません。
**注記**
T DB インスタンスクラスを、開発サーバーおよびテストサーバー、または他の本稼働以外のサーバーにのみ使用することをお勧めします。T インスタンスクラスの詳細については、「[開発やテストのための T インスタンスクラスの使用](AuroraMySQL.BestPractices.Performance.md#AuroraMySQL.BestPractices.T2Medium)」を参照してください。
MySQL エラーログで ZDP 中に重要な属性のメトリクスを確認できます。AWS マネジメントコンソール の [**イベント**] ページでは、Aurora MySQL で ZDP を使用する場合や、ZDP の使用を選択しない場合に関する情報も確認できます。
Aurora MySQL では、バイナリログレプリケーションが有効かどうかにかかわらず、Aurora はダウンタイムゼロでパッチを実行できます。バイナリログレプリケーションが有効な場合、Aurora MySQL は、ZDP オペレーション中にバイナリログターゲットへの接続を自動的に切断します。Aurora MySQL は自動的にバイナリログターゲットに再接続し、再起動の完了後にレプリケーションを再開します。
また、ZDP は、Aurora MySQL の再起動の機能拡張との組み合わせでも機能します。ライター DB インスタンスにパッチを適用すると、同時にリーダーにパッチが自動適用されます。パッチの実行後、Aurora は、ライター DB インスタンスとリーダー DB インスタンスの両方で接続を復元します。
ZDP は、以下の状態では正常に完了されない場合があります。
+ 長期実行クエリまたはトランザクションが進行中である。この場合、Aurora が ZDP を実行すると、未処理のトランザクションはすべてキャンセルされますが、接続は保持されます。
+ データ定義言語 (DDL) ステートメントの実行中などは、一時テーブル、ユーザーロック、またはテーブルロックが使用中です。Aurora はこれらの接続を切断します。
+ パラメータの変更が保留中である。
上記の状態のいずれかにより、ZDP を実行するための適切な時間枠が確保されない場合、パッチ適用はスタンダードの動作に戻ります。
ZDP オペレーションが成功した後も接続はそのまま残りますが、一部の可変と機能は再初期化されます。次の種類の情報は、ダウンタイムのないパッチ適用によって生じる再起動を通じては保持されません。
+ グローバル可変 Aurora はセッション可変を復元しますが、再起動後のグローバル可変の復元は行いません。
+ ステータス可変。特に、エンジンステータスによって報告される稼働時間の値は、ZDR または ZDP メカニズムを使用する再起動後にリセットされます。
+ `LAST_INSERT_ID`.
+ テーブルのメモリ内 `auto_increment` 状態。メモリ内自動インクリメント状態が再初期化されます。自動インクリメント値の詳細については、[MySQL リファレンスマニュアル](https://dev.mysql.com/doc/refman/5.7/en/innodb-auto-increment-handling.html#innodb-auto-increment-initialization)を参照してください。
+ `INFORMATION_SCHEMA` および `PERFORMANCE_SCHEMA` テーブルからの診断情報。この診断情報は、`SHOW PROFILE` や `SHOW PROFILES` などのコマンドの出力にも表示されます。
ダウンタイムのない再起動に関連する次のアクティビティが [**Events**] (イベント) ページで報告されます。
+ ダウンタイムなしでのデータベースのアップグレードを試みています。
+ ダウンタイムなしでのデータベースのアップグレードの試行が終了しました。イベントは、プロセスにかかった時間を報告します。このイベントでは、再起動中に保持された接続の数とドロップされた接続の数も報告されます。データベースエラーログを参照して、再起動中に発生した処理の詳細を確認できます。
## 代替のブルー/グリーンのアップグレードテクニック
状況によっては、古いクラスターからアップグレードされたクラスターへの即時の切り替えが最優先事項です。このような場合、古いクラスターと新しいクラスターを並べて実行するマルチステッププロセスを使用できます。ここでは、新しいクラスターが引き継ぐ準備ができるまで、古いクラスターから新しいクラスターにデータをレプリケートします。詳細については、[データベース更新のために Amazon Aurora ブルー/グリーンデプロイを使用する](blue-green-deployments.md) を参照してください