Amazon Aurora MySQL DB クラスターのメジャーバージョンのアップグレード

2.12.1 などの Aurora MySQL バージョン番号では、2 がメジャーバージョンを表します。Aurora MySQL バージョン 2 は MySQL 5.7 との互換性があります。Aurora MySQL バージョン 3 は MySQL 8.0 との互換性があります。

メジャーバージョン間のアップグレードでは、マイナーバージョンよりも広範な計画とテストが必要です。このプロセスにはかなりの時間がかかることがあります。アップグレードの完了後に、フォローアップ作業が必要な場合もあります。例えば、これは SQL 互換性の違いや、特定の MySQL 関連機能の動作方法の違いが原因で発生する可能性があります。または、古いバージョンと新しいバージョンでパラメータ設定が異なることが原因である可能性があります。

Aurora MySQL バージョン 2 からバージョン 3 へのアップグレード

MySQL 5.7 互換のクラスターがあり、それを MySQL-8.0 互換クラスターにアップグレードする場合は、クラスター自体でアップグレードプロセスを実行します。この種のアップグレードは、新しいクラスターを作成して行うアップグレードとは対照的なインプレースアップグレードです。この手法では、クラスターのエンドポイントやその他の特性を保持します。アップグレードは、すべてのデータを新しいクラスターボリュームにコピーする必要がないため、比較的高速で実行できます。この安定性により、アプリケーションの構成の変更を最小限に抑えることができます。また、アップグレードしたクラスターのテスト量を減らすことができます。これは、DB インスタンスとそのインスタンスクラス数はすべて同じままになるためです。

インプレースアップグレードのメカニズムでは、オペレーションの実行中に DB クラスターをシャットダウンする必要があります。Aurora はクリーンシャットダウンを実行し、トランザクションのロールバックやパージの取り消しなどの未処理のオペレーションを完了します。詳細については、「メジャーバージョンの Aurora MySQL インプレースアップグレードの仕組み」を参照してください。

インプレースアップグレード手順は簡単に実行でき、関連するアプリケーションでの構成の変更を最小限に抑えることができるため有用です。例えば、インプレースアップグレードでは、クラスターのエンドポイントと一連の DB インスタンスが保持されます。ただし、インプレースアップグレードの所要時間は、スキーマのプロパティとクラスターのビジー状態によって異なります。したがって、クラスターのニーズに応じて、複数のアップグレード方法から選択できます。

インプレースアップグレード
ブルー/グリーンデプロイ
スナップショット復元

注記
スナップショット復元のアップグレード手順に AWS CLI または RDS API を使用する場合、後続のオペレーションを実行して、復元された DB クラスターにライター DB インスタンスを作成する必要があります。

Aurora MySQL バージョン 3 および新機能に関する一般的な情報については、「Aurora MySQL バージョン 3 は MYSQL 8.0 との互換性があります。」を参照してください。

アップグレードの計画の詳細については、「Aurora MySQL クラスターのメジャーバージョンアップグレードの計画」と「インプレースアップグレードの実行手順」を参照してください。

Aurora MySQL クラスターのメジャーバージョンアップグレードの計画

アップグレードの適切な時期とアプローチを決定するには、Aurora MySQL バージョン 3 と現在の環境の違いを確認できます。

RDS for MySQL 8.0 または MySQL 8.0 Community Edition から変換する場合は、「Aurora MySQL バージョン 3 と MySQL 8.0 コミュニティエディションの比較」を参照してください。
Aurora MySQL バージョン 2、RDS for MySQL 5.7、またはコミュニティ MySQL 5.7 からアップグレードする場合は、「Aurora MySQL バージョン 2 と Aurora MySQL バージョン 3 の比較」を参照してください。
カスタムパラメータグループの新しい MySQL 8.0 互換バージョンを作成します。必要なカスタムパラメータ値を新しいパラメータグループに適用します。Aurora MySQL バージョン 3 のパラメータ変更に相談して、パラメータの変更について学びます。
MySQL 8.0 Community Edition で導入された新しい予約キーワードの使用方法について、Aurora MySQL バージョン 2 のデータベーススキーマとオブジェクト定義を確認してください。アップグレードの前に行ってください。詳細については、MySQL ドキュメントの「MySQL 8.0 の新しいキーワードと予約語」を参照してください。

MySQL 固有のアップグレードに関する考慮事項とヒントについては、MySQL リファレンスマニュアルの MySQL 8.0 での変更を参照してください。例えば、コマンド mysqlcheck --check-upgrade を使用して、既存の Aurora MySQL データベースを分析し、潜在的なアップグレードの問題を特定します。

注記

インプレースアップグレードまたはスナップショット復元技術を使用して Aurora MySQL バージョン 3 にアップグレードする場合は、大きな DB インスタンスクラスを使用することをお勧めします。例として、db.r5.24xlarge、db.r6g.16xlarge があります。これにより、DB インスタンスで使用可能な CPU 容量の大部分を使用して、アップグレードプロセスをより早く完了できます。メジャーバージョンのアップグレード完了後、必要な DB インスタンスクラスに変更できます。

アップグレード自体を完了したら、「Aurora MySQL バージョン 3 のアップグレード後のクリーンアップ」のアップグレード後の手順に従います。最後に、アプリケーションの機能とパフォーマンスをテストします。

RDS from MySQL またはコミュニティ MySQL から変換する場合は、「Amazon Aurora MySQL DB クラスターへのデータの移行」で説明している移行手順に従います。場合によっては、バイナリログレプリケーションを使用して、移行の一環として Aurora MySQL バージョン 3 クラスターとデータを同期することがあります。その場合、ソースシステムはターゲット DB クラスターとの互換性があるバージョンを実行する必要があります。

クラスターをメジャーバージョン間でアップグレードした後、アプリケーションと管理手順をスムーズに動作させるには、事前のプランと準備が必要です。AWS CLI スクリプトまたは RDS API ベースのアプリケーションの更新に使用する管理コードの種類については、「インプレースアップグレードはクラスターのパラメータグループにどのような影響を与えるか」を参照してください。また、「Aurora MySQL バージョン間のクラスターのプロパティの変更」も参照してください。

アップグレード中に発生する可能性がある問題については、「Aurora MySQL インプレースアップグレードのトラブルシューティング」を参照してください。アップグレードに長時間を要する可能性がある問題については、これらの条件を事前にテストして修正することができます。

注記

インプレースアップグレードでは、オペレーションの実行中に DB クラスターをシャットダウンする必要があります。Aurora MySQL はクリーンシャットダウンを実行し、UNDO パージなどの未処理のオペレーションを完了します。パージする UNDO レコードが多いと、アップグレードに時間がかかることがあります。履歴リストの長さ (HLL) が短くなった後にのみ、アップグレードを実行することをお勧めします。HLL の一般的な許容値は 100,000 以下です。詳細については、このブログ記事を参照してください。

DB クラスターのクローン作成によるアップグレードのシミュレーション

アップグレードしたクラスターのアプリケーションの互換性、パフォーマンス、メンテナンス手順、および同様の考慮事項を確認できます。そのためには、実際のアップグレードの実行前に、アップグレードのシミュレーションを実行できます。この手法は、本番稼働用クラスターで特に役に立ちます。ここでは、ダウンタイムを最小限に抑え、アップグレードが完了したらすぐにアップグレードされたクラスターを使用できるようにすることが重要です。

以下のステップを使用します。

元のクラスターのクローンを作成します。「Amazon Aurora DB クラスターのボリュームのクローン作成」の手順に従います。
元のクラスターと同じようなライターおよびリーダー DB インスタンスのセットを設定します。
クローンが作成されたクラスターのインプレースアップグレードを実行します。「インプレースアップグレードの実行手順」の手順に従います。

クローンを作成したら、すぐにアップグレードをスタートします。これにより、クラスターボリュームは元のクラスターと同じ状態になります。アップグレードの実行前にクローンがアイドル状態になっている場合、Aurora がバックグラウンドでデータベースのクリーンアップ処理を実行します。その場合、クローンのアップグレードは、元のクラスターのアップグレードを正確にシミュレーションしません。
クローンが作成されたクラスターを使用して、アプリケーションの互換性、パフォーマンス、管理手順などをテストします。
問題が発生した場合は、それらを考慮してアップグレードの計画を調整してください。例えば、上のバージョンの特徴セットと互換性を持たせるように、任意のアプリケーションコードを適用させます。クラスター内のデータ量を基に、アップグレードにかかる時間を推定します。クラスターがビジーではない時間にアップグレードをスケジュールすることもできます。
テストクラスターでアプリケーションとワークロードが適切に動作することが確認できたら、運用クラスターのインプレースアップグレードを実行します。
メジャーバージョンのアップグレード中のクラスターの合計ダウンタイムを最小限に抑えます。そのためには、アップグレード時にクラスターのワークロードが低いか、0 であることを確認します。特に、アップグレードのスタート時は、進行中の長時間実行トランザクションがないことを確認してください。

ブルー/グリーンアップグレード手法の使用

古いクラスターと新しいクラスターを並べて実行するブルー/グリーンデプロイを作成することもできます。ここでは、新しいクラスターが引き継ぐ準備ができるまで、古いクラスターから新しいクラスターにデータをレプリケートします。詳細については、「データベース更新のために Amazon RDS ブルー/グリーンデプロイを使用する」を参照してください。

Aurora MySQL のメジャーバージョンアップグレードの事前チェック

MySQL 8.0 には MySQL 5.7 との非互換性がいくつかあります。このような非互換性が原因で MySQL バージョン 2 からバージョン 3 へのアップグレード中に問題が生じる可能性があります。アップグレードを成功させるには、データベースで何らかの準備が必要になる場合があります。

Aurora MySQL バージョン 2 から 3 へのアップグレードをスタートすると、Amazon Aurora では、これらの非互換性を検出するために自動的に事前チェックが実行されます。

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

アップグレード中の計画外のダウンタイムを回避することができます。
非互換性がある場合、Amazon Aurora でアップグレードすることはできません。詳細を示すログが出力されます。ログを使用して、非互換性を排除することにより、データベースをバージョン 3 にアップグレードする準備を行うことができます。非互換性の排除の詳細については、MySQL ドキュメントの「アップグレードのためのインストールの準備」と「MySQL 8.0? へのアップグレード」を参照してください。MySQL Server ブログの「知っておくべきこと」を参照してください。

MySQL 8.0 へのアップグレードの詳細については、MySQL ドキュメントの「MySQL のアップグレード」を参照してください。

事前チェックには、MySQL に含まれている証明書と Aurora チーム用によって特別に作成された証明書が含まれます。MySQL が提供する事前確認については、Upgrade Checker Utility」を参照してください。

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

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

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

コミュニティ MySQL アップグレードの事前チェック

以下は、MySQL 5.7 から 8.0 までの非互換性の一般的なリストです。

MySQL 5.7 互換 DB クラスターでは、MySQL 8.0 でサポートされていない機能を使用しないでください。

詳細については、MySQL ドキュメントの「MySQL 8.0 で削除された機能」を参照してください。
キーワードや予約語に違反してはいけません。MySQL 8.0 では、以前に予約されていなかったキーワードもあります。

詳細については、MySQL ドキュメントの「キーワードと予約語」を参照してください。
Unicode サポートが向上するように、utf8mb3 文字セットを使用するように、utf8mb4 文字セットを使用するオブジェクトを変換することを検討してください。utf8mb3 文字セットは廃止されました。また、utf8mb4 の代わりに utf8 を文字セット参照に使用することを検討してください。現在 utf8 は utf8mb3 文字セットの別名であるためです。

詳細については、MySQL ドキュメントの「utf8mb3 文字セット (3 バイトの UTF-8 Unicode エンコード)」を参照してください。
デフォルト以外の行形式の InnoDB テーブルは使用できません。
ZEROFILL または display の長さ型属性は使用できません。
ネイティブのパーティショニングをサポートしていないストレージエンジンを使用するパーティショニングされたテーブルがあってはいけません。
MySQL 5.7 の mysql システムデータベースに、MySQL 8.0 データディクショナリで使用されるテーブルと同じ名前のテーブルがあってはいけません。
テーブルで古いデータ型や関数を使用してはいけません。
64 文字を超える外部キーの制約名があってはいけません。
sql_mode システム可変設定で、古い SQL モードを定義してはいけません。
長さが 255 文字を超える ENUM または SET 列要素をそれぞれ持つテーブルまたはストアドプロシージャが存在してはいけません。
共有 InnoDB テーブルスペースに存在するテーブルパーティションが存在してはいけません。
表領域データファイルパスに循環参照が存在してはいけません。
ASC 句に DESC または GROUP BY 修飾子を使用するクエリおよびストアドプログラム定義が存在してはいけません。
削除されたシステム変数が存在してはならず、システム変数は MySQL 8.0 の新しいデフォルト値を使用する必要があります。
ゼロ (0) の日付、日時、タイムスタンプ値は使用できません。
ファイルの削除または破損によるスキーマの不一致が存在してはいけません。
FTS 文字列を含むテーブル名が存在してはいけません。
別のエンジンに属する InnoDB テーブルが存在してはいけません。
MySQL 5.7 に無効なテーブル名またはスキーマ名が存在してはいけません。

MySQL 8.0 へのアップグレードの詳細については、MySQL ドキュメントの「MySQL のアップグレード」を参照してください。

Aurora MySQL のアップグレードの事前チェック

バージョン 2 からバージョン 3 にアップグレードする場合、Aurora MySQL には独自の固有要件があります。

ビュー、ルーチン、トリガー、イベントに、SQL_CACHE、SQL_NO_CACHE、QUERY_CACHE などの非推奨の SQL 構文があってはいけません。
FTS インデックスのないテーブルには FTS_DOC_ID 列が存在しない必要があります。
InnoDB データディクショナリと実際のテーブル定義の間に列定義の不一致が存在してはいけません。
lower_case_table_names パラメータが 1 に設定されている場合は、すべてのデータベース名とテーブル名を小文字にする必要があります。
イベントとトリガーの definer は欠落していても、空にすることもできず、トリガーに無効な作成コンテキストでもいけません。
データベース内のすべてのトリガー名は一意である必要があります。
DDL リカバリと高速 DDL は、Aurora MySQL バージョン 3 ではサポートされていません。これらの機能に関連するデータベースにアーティファクトが存在してはいけません。
REDUNDANT または COMPACT行形式のテーブルには、767 バイトを超えるインデックスを含めることはできません。
tiny テキスト列に定義されているインデックスのプレフィックスの長さは 255 バイトを超えることはできません。utf8mb4 文字セットでは、サポートされるプレフィックスの長さは 63 文字に制限されます。

MySQL 5.7 では、innodb_large_prefix パラメータを使用して、より大きなプレフィックスの長さが許可されました。このパラメータは MySQL 8.0 では廃止されました。
mysql.host テーブルに InnoDB メタデータの不整合が存在してはいけません。
システムテーブルに列のデータ型の不一致が存在してはいけません。
prepared 状態の XA トランザクションが存在してはいけません。
ビューの列名は 64 文字以下にする必要があります。
ストアドプロシージャの特殊文字に一貫性を持たせることはできません。
テーブルにデータファイルパスの不整合が存在してはいけません。

Aurora MySQL メジャーバージョンのアップグレードプロセス

すべての種類またはバージョンの Aurora MySQL クラスターでインプレースアップグレードメカニズムを使用できるわけではありません。次の表を参照して、各 Aurora MySQL クラスターの適切なアップグレードパスを確認してください。

Aurora MySQL DB クラスターのタイプ	インプレースアップグレードを使用できますか?	アクション
Aurora MySQL プロビジョニングされたクラスター、2.0 以降	はい	インプレースアップグレードは、5.7 互換 Aurora MySQL クラスターでサポートされます。 Aurora MySQL バージョン 3 へのアップグレードの詳細については、Aurora MySQL クラスターのメジャーバージョンアップグレードの計画とインプレースアップグレードの実行手順を参照してください。
Aurora MySQL プロビジョニングされたクラスター、3.01.0 以降	該当なし	Aurora MySQL バージョン 3 バージョン間でアップグレードするには、マイナーバージョンアップグレード手順を使用してください。
Aurora Serverless v1 クラスター	該当なし	現時点では、Aurora Serverless v1 はバージョン 2 でのみ Aurora MySQL でサポートされています。
Aurora Serverless v2 クラスター	該当なし	現時点では、Aurora Serverless v2 はバージョン 3 でのみ Aurora MySQL でサポートされています。
Aurora Global Database のクラスター	はい	Aurora MySQL をバージョン 2 からバージョン 3 にアップグレードするには、Aurora グローバルデータベースでクラスターのインプレースアップグレードを実行する手順に従います。グローバルクラスターでアップグレードを実行します。Aurora は、グローバルデータベースのプライマリクラスター、ならびにすべてのセカンダリクラスターに対し、同時に自動アップグレードを実行します。 AWS CLI または RDS API を使用する場合は、`modify-global-cluster` または `ModifyGlobalCluster` の代わりに `modify-db-cluster` コマンドまたは `ModifyDBCluster` オペレーションを呼び出します。 `lower_case_table_names` パラメータがオンの場合、Aurora MySQL バージョン 2 からバージョン 3 へのインプレースアップグレードを実行できません。詳細については、「メジャーバージョンのアップグレード」を参照してください。
パラレルクエリクラスター	はい	インプレースアップグレードを実行できます。この場合、Aurora MySQL バージョンに 2.09.1 以降を選択します。
バイナリログレプリケーションのターゲットのクラスター	おそらく	バイナリログのレプリケーションが Aurora MySQL クラスターからのものであれば、インプレースアップグレードを実行できます。バイナリログのレプリケーションが RDS for MySQL またはオンプレミス MySQL DB インスタンスからのものである場合は、アップグレードを実行できません。その場合は、スナップショットの復元メカニズムを使用してアップグレードします。
DB インスタンスがゼロのクラスター	いいえ	AWS CLI または RDS API を使用すると、DB インスタンスをアタッチせずに、 Aurora MySQL クラスターを作成できます。同様に、クラスターボリューム内のデータをそのまま残しつつ、Aurora MySQL クラスターからすべての DB インスタンスを削除することもできます。クラスターに DB インスタンスがない場合、インプレースアップグレードを実行することはできません。アップグレードメカニズムでは、システムテーブルやデータファイルなどに対して変換を実行するため、クラスターのライターインスタンスが必要です。この場合、AWS CLI または RDS API を使用して、クラスターのライターインスタンスを作成します。その後、インプレースアップグレードを実行します。
バックトラックが有効なクラスター	はい	バックトラック機能を使用する Aurora MySQL クラスターのインプレースアップグレードを実行できます。ただし、アップグレード後は、クラスターをアップグレード前の時間までバックトラックすることはできません。

メジャーバージョンの Aurora MySQL インプレースアップグレードの仕組み

Aurora MySQL は、メジャーバージョンのアップグレードを多段階プロセスとして実行します。アップグレードの現在のステータスを確認できます。アップグレードの一部のステップでは、進捗情報も確認できます。各ステージのスタート時に、Aurora MySQL によってイベントが記録されます。RDS コンソールの [イベント] ページで、発生したイベントを確認できます。イベントの使用の詳細については、「Amazon RDS イベント通知の操作」を参照してください。

重要

プロセスがスタートされると、アップグレードが成功または失敗するまで実行されます。進行中は、アップグレードをキャンセルできません。アップグレードが失敗した場合、Aurora はすべての変更をロールバックし、クラスターのエンジンバージョン、メタデータなどが前と同じ状態になります。

アップグレードプロセスには、3 つのステージがあります。

Aurora は、アップグレードプロセスをスタートする前に一連の事前チェックを実行します。Aurora がこれらのチェックを実行している間、クラスターは実行を続けます。例えば、クラスターは、準備済みステートメントの XA トランザクションを使用したり、データ定義言語 (DDL) ステートメントを処理したりすることはできません。例えば、特定の種類の SQL ステートメントを送信中のアプリケーションをシャットダウンする必要がある場合があります。または、長時間実行される特定のステートメントが終了するまで待たなければならない可能性もあります。その場合は、アップグレードを再試行してください。一部のチェックでは、アップグレードの妨げにはならないものの、アップグレードに長時間かかる可能性がある条件をテストします。

Aurora で必要な条件が満たされていないことが検出された場合は、イベントの詳細に示されている条件を変更します。Aurora MySQL インプレースアップグレードのトラブルシューティングのガイダンスに従います。Aurora で、アップグレードを遅らせる原因となる条件が検出された場合は、長期間にわたりアップグレードをモニタリングすることを計画します。
Aurora はクラスターをオフラインにします。次に、Aurora が前のステージと同様の一連のテストを実行し、シャットダウンプロセス中に新たな問題が発生していないことを確認します。この時点で、Aurora がアップグレードの妨げになる条件を検出した場合、Aurora はアップグレードをキャンセルし、クラスターをオンラインに戻します。この場合、条件がいつから適用されていないかを確認し、アップグレードを再度スタートします。
Aurora は、クラスターボリュームのスナップショットを作成します。アップグレードの完了後に、互換性やその他の種類の問題を発見したとします。または、元のクラスターとアップグレードされたクラスターの両方を使用してテストを実行するとします。このような場合、このスナップショットから復元し、元のエンジンバージョンと元のデータを使用して新しいクラスターを作成することができます。

ヒント
このスナップショットは手動スナップショットです。ただし、Aurora は、手動スナップショットのクォータに達した場合でも、それを作成してアップグレードプロセスを続行することができます。このスナップショットは、削除するまで永続的に残ります (必要な場合)。アップグレード後のテストをすべて完了したら、このスナップショットを削除してストレージ料金を最小限に抑えることができます。
クラスターボリュームの Aurora クローンを作成します。クローン作成は、実際のテーブルデータのコピーを伴わない高速オペレーションです。アップグレード中、Aurora に問題が発生すると、クローンが作成されたクラスターボリュームから元のデータに戻り、クラスターをオンラインに戻します。アップグレード中のクローン作成の一時ボリュームは、単一のクラスターボリュームでの通常のクローン数の制限を受けません。
Aurora は、ライター DB インスタンスのクリーンシャットダウンを実行します。クリーンシャットダウン中は、以下のオペレーションの進行状況イベントが 15 分ごとに記録されます。RDS コンソールの [イベント] ページで、発生したイベントを確認できます。
- Aurora は、古いバージョンの行の UNDO レコードを消去します。
- Aurora は、コミットされていないトランザクションをロールバックします。
Aurora は、ライター DB インスタンスのエンジンバージョンをアップグレードします。
- Aurora は、新しいエンジンバージョンのバイナリをライター DB インスタンスにインストールします。
- Aurora は、ライター DB インスタンスを使用して、データを MySQL 5.7 互換のフォーマットにアップグレードします。このステージでは、Aurora によってシステムテーブルが変更され、クラスターボリュームのデータに影響を与えるその他の変換が実行されます。特に、Aurora はシステムテーブル内のパーティションのメタデータをアップグレードして、MySQL 5.7 のパーティションのフォーマットとの互換性を持たせます。クラスター内のテーブルに多数のパーティションがある場合、このステージには長時間かかります。
  
  このステージでエラーが発生した場合は、MySQL エラーログで詳細を確認できます。このステージのスタート後に何らかの理由でアップグレードプロセスが失敗した場合、Aurora はクローンが作成されたクラスターボリュームから元のデータを復元します。
Aurora は、リーダー DB インスタンスのエンジンバージョンをアップグレードします。
アップグレードプロセスは完了しました。アップグレードプロセスが正常に完了したことを示す最終イベントが、Aurora により記録されます。DB クラスターが新しいメジャーバージョンで実行されています。

代替の Blue/Green のアップグレードテクニック

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

インプレースアップグレードの実行手順

メジャーバージョンの Aurora MySQL インプレースアップグレードの仕組みの背景のマテリアルを確認することをお勧めします。

「Aurora MySQL クラスターのメジャーバージョンアップグレードの計画」の説明に従い、アップグレード前の計画とテストを行います。

次の例では、mydbcluster-cluster DB クラスターを Aurora MySQL バージョン 3.04.1 にアップグレードします。

Aurora MySQL DB クラスターのメジャーバージョンをアップグレードするには

AWS Management Console にサインインし、Amazon RDS コンソール https://console.aws.amazon.com/rds/ を開きます。
元の DB クラスターでカスタムパラメータグループを使用した場合は、新しいメジャーバージョン互換のパラメータグループを作成します。新しいパラメータグループの設定パラメータに必要な調整を行います。詳細については、「インプレースアップグレードはクラスターのパラメータグループにどのような影響を与えるか」を参照してください。
ナビゲーションペインで、[データベース] を選択します。
リストから、変更する DB クラスターを選択します。
Modify を選択します。
[Version] (バージョン) で、新しい Aurora MySQL のメジャーバージョンを選択します。

通常、メジャーバージョンの最新のマイナーバージョンを使用することをお勧めします。ここでは、現在のデフォルトバージョンを選択します。
Continue (続行) をクリックします。
次のページで、アップグレードを実行するタイミングを指定します。[次の定期メンテナンス期間中] または [今すぐ] を選択します。
(オプション) アップグレード中、RDS コンソールの [イベント] ページを定期的に確認します。これにより、アップグレードの進行状況をモニタリングし、問題を特定することができます。アップグレードで問題が発生した場合は、Aurora MySQL インプレースアップグレードのトラブルシューティングを参照してステップを実行してください。
この手順のスタート時に、新しいパラメータグループを作成した場合は、アップグレードしたクラスターにカスタムパラメータグループを関連付けます。詳細については、「インプレースアップグレードはクラスターのパラメータグループにどのような影響を与えるか」を参照してください。

注記
このステップを実行するには、クラスターを再起動して新しいパラメータグループを適用する必要があります。
(オプション) アップグレード後のテストが完了したら、アップグレードのスタート時に Aurora によって作成された手動スナップショットを削除します。

Aurora MySQL DB クラスターのメジャーバージョンをアップグレードするには、次の必須パラメータを指定しながら、AWS CLI の modify-db-cluster コマンドを実行します。

--db-cluster-identifier
--engine-version
--allow-major-version-upgrade
--apply-immediately または --no-apply-immediately

クラスターでカスタムパラメータグループを使用する場合は、次のオプションの 1 つ、または両方を含めます。

--db-cluster-parameter-group-name、クラスターがカスタムクラスターのパラメータグループを使用している場合
--db-instance-parameter-group-name、クラスター内のインスタンスがカスタム DB のパラメータグループを使用している場合

次の例では、sample-cluster DB クラスターを Aurora MySQL バージョン 3.04.1 にアップグレードします。アップグレードは、次のメンテナンスウィンドウを待つことなく、すぐに実行されます。

例

Linux、macOS、Unix の場合:


aws rds modify-db-cluster \
          --db-cluster-identifier sample-cluster \
          --engine-version 8.0.mysql_aurora.3.04.1 \
          --allow-major-version-upgrade \
          --apply-immediately

Windows の場合:


aws rds modify-db-cluster ^
          --db-cluster-identifier sample-cluster ^
          --engine-version 8.0.mysql_aurora.3.04.1 ^
          --allow-major-version-upgrade ^
          --apply-immediately

他の CLI modify-db-cluster コマンドをと組み合わせて、アップグレードを実行および検証するための自動化されたエンドツーエンドのプロセスを作成できます。詳細な説明と例については、「Aurora MySQL インプレースアップグレードのチュートリアル」を参照してください。

注記

クラスターが Aurora Global Database の一部である場合、インプレースアップグレードの手順は若干異なります。modify-db-cluster の代わりに、modify-global-cluster コマンドオペレーションを呼び出します。詳細については、「グローバルデータベースのインプレースメジャーアップグレード」を参照してください。

Aurora MySQL DB クラスターのメジャーバージョンをアップグレードするには、次の必須パラメータを指定して RDS API の ModifyDBCluster オペレーションを使用します。

DBClusterIdentifier
Engine
EngineVersion
AllowMajorVersionUpgrade
ApplyImmediately (true、または false に設定)

注記

クラスターが Aurora Global Database の一部である場合、インプレースアップグレードの手順は若干異なります。 ModifyDBCluster の代わりに、 modifyGlobalCluster オペレーションを呼び出します。詳細については、「グローバルデータベースのインプレースメジャーアップグレード」を参照してください。

インプレースアップグレードはクラスターのパラメータグループにどのような影響を与えるか

Aurora パラメータグループには、MySQL 5.7 または 8.0 と互換性のあるクラスターとは異なる構成設定のセットがあります。インプレースアップグレードを実行する際、アップグレードされたクラスターとそのすべてのインスタンスで、対応するクラスターおよびインスタンスのパラメータグループを使用する必要があります。

クラスターとインスタンスは、デフォルトの 5.7 互換パラメータグループを使用する場合があります。その場合、アップグレードされたクラスターとインスタンスは、デフォルトの 8.0 互換パラメータグループで開始されます。クラスターとインスタンスでカスタムパラメータグループを使用している場合は、対応する、または 8.0 互換のパラメータグループを作成してください。また、アップグレード処理中に必ずそれらを指定してください。

注記

ほとんどのパラメータ設定では、2 つのポイントでカスタムパラメータグループを選択できます。これらは、クラスターの作成時や、パラメータグループをクラスターに関連付ける場合です。

ただし、デフォルト以外の設定を lower_case_table_names パラメータに使用する場合は、事前にこの設定を使用してカスタムパラメータグループを設定する必要があります。その後、スナップショット復元を実行してクラスターを作成する際、パラメータグループを指定します。クラスター作成後のlower_case_table_names パラメータへの変更は、影響がありません。

Aurora MySQL バージョン 2 からバージョン 3 にアップグレードする場合にも、同じ lower_case_table_names の設定を使用することをお勧めします。

Aurora MySQL に基づく Aurora グローバルデータベースでは、lower_case_table_names パラメータがオンの場合、Aurora MySQL バージョン 2 からバージョン 3 へのインプレースアップグレードを実行できません。使用できる方法の詳細については、「メジャーバージョンのアップグレード」を参照してください。

重要

アップグレードプロセス中にカスタムパラメータグループを指定した場合は、アップグレード終了後にクラスターを手動で再起動してください。再起動すると、クラスターがカスタムパラメータ設定の使用をスタートできます。

Aurora MySQL バージョン間のクラスターのプロパティの変更

Aurora MySQL バージョン 2 からバージョン 3 にアップグレードする場合は、Aurora MySQL クラスターと DB インスタンスのセットアップと管理に使用するアプリケーションやスクリプトを確認してください。

また、5.7 および 8.0 互換クラスターではデフォルトのパラメータグループ名が異なることを考慮して、パラメータグループを操作するコードを変更します。Aurora MySQL バージョン 2 と 3 のクラスターのデフォルトのパラメータグループ名は、それぞれ default.aurora-mysql5.7 と default.aurora-mysql8.0 です。

例えば、アップグレード前にクラスターに適用される次のようなコードがあるとします。


# Check the default parameter values for MySQL 5.7–compatible clusters.
aws rds describe-db-parameters --db-parameter-group-name default.aurora-mysql5.7 --region us-east-1

クラスターのメジャーバージョンをアップグレードした後、そのコードを次のように変更します。


# Check the default parameter values for MySQL 8.0–compatible clusters.
aws rds describe-db-parameters --db-parameter-group-name default.aurora-mysql8.0 --region us-east-1

グローバルデータベースのインプレースメジャーアップグレード

Aurora Global Database の場合は、グローバルデータベースクラスターをアップグレードします。Aurora は、すべてのクラスターを同時かつ自動的にアップグレードし、すべてのクラスターで、同じエンジンバージョンが実行されることを保証します。これは、システムテーブルやデータファイル形式などの変更が、すべてのセカンダリクラスターに自動的にレプリケートされるためです。

「メジャーバージョンの Aurora MySQL インプレースアップグレードの仕組み」の手順に従いますアップグレードする対象を指定するときは、そのデータベースに含まれるクラスターの 1 つではなく、グローバルデータベースクラスターを選択してください。

AWS Management Console を使用する場合、[Global database] (グローバルデータベース) のロールを持つアイテムを選択します。

AWS CLI または RDS API を使用する場合は、modify-global-cluster コマンドまたは ModifyGlobalCluster オペレーションを呼び出して、アップグレードプロセスをスタートします。modify-db-cluster または ModifyDBCluster の代わりにこれらのいずれかを使用します。

注記

Aurora グローバルデータベースのメジャーバージョンアップグレードを実行している間、グローバルデータベースクラスターのカスタムパラメータグループを指定することはできません。グローバルクラスターの各リージョンにカスタムパラメータグループを作成します。次に、アップグレード後に手動でリージョンクラスターに適用します。

AWS CLI を使用して Aurora MySQL グローバルデータベースクラスターのメジャーバージョンをアップグレードするには、以下の必須パラメータを指定して、modify-global-cluster コマンドを使用します。

--global-cluster-identifier
--engine aurora-mysql
--engine-version
--allow-major-version-upgrade

次の例では、グローバルデータベースクラスターを Aurora MySQL バージョン 2.10.2 にアップグレードします。

例

Linux、macOS、Unix の場合:


aws rds modify-global-cluster \
          --global-cluster-identifier global_cluster_identifier \
          --engine aurora-mysql \
          --engine-version 5.7.mysql_aurora.2.10.2 \
          --allow-major-version-upgrade

Windows の場合:


aws rds modify-global-cluster ^
          --global-cluster-identifier global_cluster_identifier ^
          --engine aurora-mysql ^
          --engine-version 5.7.mysql_aurora.2.10.2 ^
          --allow-major-version-upgrade

バックトラックに関する考慮事項

アップグレードしたクラスターでバックトラック機能が有効になっている場合、アップグレードしたクラスターをアップグレード前の時間にバックトラックすることはできません。

Aurora MySQL インプレースアップグレードのチュートリアル

次の Linux の例では、AWS CLI を使用してインプレースアップグレードの一般的なステップを実行する方法を示します。

この最初の例では、2.x バージョンの Aurora MySQL を実行する Aurora DB クラスターを作成します。クラスターには、ライター DB インスタンスとリーダー DB インスタンスが含まれます。wait db-instance-available コマンドは、ライター DB インスタンスが利用可能になるまで一時停止します。クラスターをアップグレードする準備ができた時点です。


aws rds create-db-cluster --db-cluster-identifier mynewdbcluster --engine aurora-mysql \
  --db-cluster-version 5.7.mysql_aurora.2.10.2
...
aws rds create-db-instance --db-instance-identifier mynewdbcluster-instance1 \
  --db-cluster-identifier mynewdbcluster --db-instance-class db.t4g.medium --engine aurora-mysql
...
aws rds wait db-instance-available --db-instance-identifier mynewdbcluster-instance1

クラスターをアップグレードできる Aurora MySQL 3.x バージョンは、クラスターが現在実行している 2.x バージョンと、クラスターがある AWS リージョンによって異なります。--output text による初期のコマンドは、使用可能なターゲットバージョンだけを表示させます。2 番目のコマンドは、レスポンスの完全な JSON 出力を表示します。その応答では、engine パラメータに使用した aurora-mysql 値などの詳細を確認できます。また、3.02.0 へのアップグレードがメジャーバージョンアップグレードであることがわかります。


aws rds describe-db-clusters --db-cluster-identifier mynewdbcluster \
  --query '*[].{EngineVersion:EngineVersion}' --output text
5.7.mysql_aurora.2.10.2

aws rds describe-db-engine-versions --engine aurora-mysql --engine-version 5.7.mysql_aurora.2.10.2 \
  --query '*[].[ValidUpgradeTarget]'
...
{
    "Engine": "aurora-mysql",
    "EngineVersion": "8.0.mysql_aurora.3.02.0",
    "Description": "Aurora MySQL 3.02.0 (compatible with MySQL 8.0.23)",
    "AutoUpgrade": false,
    "IsMajorVersionUpgrade": true,
    "SupportedEngineModes": [
        "provisioned"
    ],
    "SupportsParallelQuery": true,
    "SupportsGlobalDatabases": true,
    "SupportsBabelfish": false
},
...

この例では、クラスターの有効なアップグレードターゲットではないターゲットバージョン番号が入力された場合に、Aurora がアップグレードを実行しないようにする方法を示しています。Aurora は、--allow-major-version-upgrade パラメータを指定しない限り、メジャーバージョンのアップグレードを実行しません。これにより、アプリケーションコードの大規模なテストや変更を必要とする可能性のあるアップグレードを誤って実行することはありません。


aws rds modify-db-cluster --db-cluster-identifier mynewdbcluster \
  --engine-version 5.7.mysql_aurora.2.09.2 --apply-immediately
An error occurred (InvalidParameterCombination) when calling the ModifyDBCluster operation: Cannot find upgrade target from 5.7.mysql_aurora.2.10.2 with requested version 5.7.mysql_aurora.2.09.2.

aws rds modify-db-cluster --db-cluster-identifier mynewdbcluster \
  --engine-version 8.0.mysql_aurora.3.02.0 --region us-east-1 --apply-immediately
An error occurred (InvalidParameterCombination) when calling the ModifyDBCluster operation: The AllowMajorVersionUpgrade flag must be present when upgrading to a new major version.

aws rds modify-db-cluster --db-cluster-identifier mynewdbcluster \
  --engine-version 8.0.mysql_aurora.3.02.0 --apply-immediately --allow-major-version-upgrade
{
  "DBClusterIdentifier": "mynewdbcluster",
  "Status": "available",
  "Engine": "aurora-mysql",
  "EngineVersion": "5.7.mysql_aurora.2.10.2"
}

クラスターおよび関連付けられた DB インスタンスのステータスが upgrading に変わるまで、しばらく時間がかかります。クラスターおよび DB インスタンスのバージョン番号は、アップグレードが完了したときにのみ変更されます。この場合も、ライター DB インスタンスの wait db-instance-available コマンドを使用して、アップグレードが完了するまで待機してから続行します。


aws rds describe-db-clusters --db-cluster-identifier mynewdbcluster \
  --query '*[].[Status,EngineVersion]' --output text
upgrading 5.7.mysql_aurora.2.10.2

aws rds describe-db-instances --db-instance-identifier mynewdbcluster-instance1 \
  --query '*[].{DBInstanceIdentifier:DBInstanceIdentifier,DBInstanceStatus:DBInstanceStatus} | [0]'
{
    "DBInstanceIdentifier": "mynewdbcluster-instance1",
    "DBInstanceStatus": "upgrading"
}

aws rds wait db-instance-available --db-instance-identifier mynewdbcluster-instance1

この時点で、クラスターのバージョン番号が、アップグレード用に指定されたバージョン番号と一致します。


aws rds describe-db-clusters --db-cluster-identifier mynewdbcluster \
  --query '*[].[EngineVersion]' --output text

8.0.mysql_aurora.3.02.0

前の例では、--apply-immediately パラメータを指定して即時のアップグレードを実行しました。クラスターがビジー状態ではないと予想される都合の良いときにアップグレードを実行するために、--no-apply-immediately パラメータを指定できます。これにより、クラスターの次のメンテナンスウィンドウの表示中にアップグレードがスタートされます。メンテナンスウィンドウでは、メンテナンスオペレーションをスタートできる期間を定義します。長時間実行されるオペレーションは、メンテナンスウィンドウの中で終了しない場合があります。したがって、アップグレードに長時間かかることが予想される場合でも、より大きなメンテナンスウィンドウを定義する必要はありません。

次の例では、初期に Aurora MySQL バージョン 2.10.2 を実行しているクラスターをアップグレードします。describe-db-engine-versions 出力では、False および True 値は IsMajorVersionUpgrade プロパティを表します。バージョン 2.10.2 から、他の 2.* バージョンにアップグレードできます。これらのアップグレードはメジャーバージョンアップグレードとはみなされないため、一括アップグレードは必要ありません。インプレースアップグレードは、リストに示されている 3.* バージョンへのアップグレードでのみ利用できます。


aws rds describe-db-clusters --db-cluster-identifier mynewdbcluster \
  --query '*[].{EngineVersion:EngineVersion}' --output text
5.7.mysql_aurora.2.10.2

aws rds describe-db-engine-versions --engine aurora-mysql --engine-version 5.7.mysql_aurora.2.10.2 \
  --query '*[].[ValidUpgradeTarget]|[0][0]|[*].[EngineVersion,IsMajorVersionUpgrade]' --output text

5.7.mysql_aurora.2.10.3 False
5.7.mysql_aurora.2.11.0 False
5.7.mysql_aurora.2.11.1 False
8.0.mysql_aurora.3.01.1 True
8.0.mysql_aurora.3.02.0 True
8.0.mysql_aurora.3.02.2 True


aws rds modify-db-cluster --db-cluster-identifier mynewdbcluster \
  --engine-version 8.0.mysql_aurora.3.02.0 --no-apply-immediately --allow-major-version-upgrade
...

指定されたメンテナンスウィンドウを使用せずにクラスターを作成する場合、Aurora はランダムな曜日を選択します。この場合、modify-db-cluster コマンドは月曜日に送信されます。したがって、メンテナンスウィンドウを火曜日の朝に変更します。すべての時刻は UTC タイムゾーンで表されます。tue:10:00-tue:10:30 期間は、太平洋標準時の午前 2 時から 2 時 30 分に相当します。メンテナンスウィンドウの変更はすぐに有効になります。


aws rds describe-db-clusters --db-cluster-identifier mynewdbcluster --query '*[].[PreferredMaintenanceWindow]'
[
    [
        "sat:08:20-sat:08:50"
    ]
]

aws rds modify-db-cluster --db-cluster-identifier mynewdbcluster --preferred-maintenance-window tue:10:00-tue:10:30"
aws rds describe-db-clusters --db-cluster-identifier mynewdbcluster --query '*[].[PreferredMaintenanceWindow]'
[
    [
        "tue:10:00-tue:10:30"
    ]
]

次に、アップグレードによって生成されたイベントのレポートを取得する例を示します。--duration 引数は、イベント情報を取得する時間 (分) を表します。デフォルトでは、describe-events は過去 1 時間のイベントのみを返すため、この引数が必要です。


aws rds describe-events --source-type db-cluster --source-identifier mynewdbcluster --duration 20160
{
    "Events": [
        {
            "SourceIdentifier": "mynewdbcluster",
            "SourceType": "db-cluster",
            "Message": "DB cluster created",
            "EventCategories": [
                "creation"
            ],
            "Date": "2022-11-17T01:24:11.093000+00:00",
            "SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
        },
        {
            "SourceIdentifier": "mynewdbcluster",
            "SourceType": "db-cluster",
            "Message": "Upgrade in progress: Performing online pre-upgrade checks.",
            "EventCategories": [
                "maintenance"
            ],
            "Date": "2022-11-18T22:57:08.450000+00:00",
            "SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
        },
        {
            "SourceIdentifier": "mynewdbcluster",
            "SourceType": "db-cluster",
            "Message": "Upgrade in progress: Performing offline pre-upgrade checks.",
            "EventCategories": [
                "maintenance"
            ],
            "Date": "2022-11-18T22:57:59.519000+00:00",
            "SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
        },
        {
            "SourceIdentifier": "mynewdbcluster",
            "SourceType": "db-cluster",
            "Message": "Upgrade in progress: Creating pre-upgrade snapshot [preupgrade-mynewdbcluster-5-7-mysql-aurora-2-10-2-to-8-0-mysql-aurora-3-02-0-2022-11-18-22-55].",
            "EventCategories": [
                "maintenance"
            ],
            "Date": "2022-11-18T23:00:22.318000+00:00",
            "SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
        },
        {
            "SourceIdentifier": "mynewdbcluster",
            "SourceType": "db-cluster",
            "Message": "Upgrade in progress: Cloning volume.",
            "EventCategories": [
                "maintenance"
            ],
            "Date": "2022-11-18T23:01:45.428000+00:00",
            "SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
        },
        {
            "SourceIdentifier": "mynewdbcluster",
            "SourceType": "db-cluster",
            "Message": "Upgrade in progress: Purging undo records for old row versions. Records remaining: 164",
            "EventCategories": [
                "maintenance"
            ],
            "Date": "2022-11-18T23:02:25.141000+00:00",
            "SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
        },
        {
            "SourceIdentifier": "mynewdbcluster",
            "SourceType": "db-cluster",
            "Message": "Upgrade in progress: Purging undo records for old row versions. Records remaining: 164",
            "EventCategories": [
                "maintenance"
            ],
            "Date": "2022-11-18T23:06:23.036000+00:00",
            "SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
        },
        {
            "SourceIdentifier": "mynewdbcluster",
            "SourceType": "db-cluster",
            "Message": "Upgrade in progress: Upgrading database objects.",
            "EventCategories": [
                "maintenance"
            ],
            "Date": "2022-11-18T23:06:48.208000+00:00",
            "SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
        },
        {
            "SourceIdentifier": "mynewdbcluster",
            "SourceType": "db-cluster",
            "Message": "Database cluster major version has been upgraded",
            "EventCategories": [
                "maintenance"
            ],
            "Date": "2022-11-18T23:10:28.999000+00:00",
            "SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
        }
    ]
}

アップグレードが失敗した理由の確認

前のチュートリアルでは、Aurora MySQL バージョン 2 からバージョン 3 へのアップグレードに成功しました。ただし、アップグレードが失敗した場合は、必要に応じて、その理由を確認できます。

まず、describe-events AWS CLI コマンドを使用して DB クラスターのイベントを表示できます。この例は、過去 10 時間の mydbcluster のイベントを示しています。


aws rds describe-events \
    --source-type db-cluster \
    --source-identifier mydbcluster \
    --duration 600

この例では、アップグレードの事前チェックが失敗しています。


{
    "Events": [
        {
            "SourceIdentifier": "mydbcluster",
            "SourceType": "db-cluster",
            "Message": "Database cluster engine version upgrade started.",
            "EventCategories": [
                "maintenance"
            ],
            "Date": "2024-04-11T13:23:22.846000+00:00",
            "SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mydbcluster"
        },
        {
            "SourceIdentifier": "mydbcluster",
            "SourceType": "db-cluster",
            "Message": "Database cluster is in a state that cannot be upgraded: Upgrade prechecks failed. For more details, see the  
             upgrade-prechecks.log file. For more information on troubleshooting the cause of the upgrade failure, see 
             https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Updates.MajorVersionUpgrade.html#AuroraMySQL.Upgrading.Troubleshooting.",
            "EventCategories": [
                "maintenance"
            ],
            "Date": "2024-04-11T13:23:24.373000+00:00",
            "SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mydbcluster"
        }
    ]
}

問題の正確な原因を診断するには、ライター DB インスタンスのデータベースログを調べます。Aurora MySQL バージョン 3 へのアップグレードが失敗すると、ライターインスタンスに upgrade-prechecks.log という名前のログファイルが追加されます。この例では、そのログの存在を検出し、それを調査のためにローカルファイルにダウンロードする方法を示します。


aws rds describe-db-log-files --db-instance-identifier mydbcluster-instance \
    --query '*[].[LogFileName]' --output text

error/mysql-error-running.log
error/mysql-error-running.log.2024-04-11.20
error/mysql-error-running.log.2024-04-11.21
error/mysql-error.log
external/mysql-external.log
upgrade-prechecks.log

aws rds download-db-log-file-portion --db-instance-identifier mydbcluster-instance \
    --log-file-name upgrade-prechecks.log \
    --starting-token 0 \
    --output text >upgrade_prechecks.log

この upgrade-prechecks.log ファイルは JSON 形式です。別の JSON ラッパー内で JSON 出力がエンコードされないように、--output text オプションを使用してこのファイルをダウンロードします Aurora MySQL バージョン 3 のアップグレードでは、このログには常に、特定の情報と警告メッセージが含まれます。エラーメッセージは、アップグレードが失敗した場合にのみ含まれます。アップグレードが成功すると、ログファイルはまったく生成されません。

すべてのエラーを集約して関連するオブジェクトや説明のフィールドを表示するには、upgrade-prechecks.log ファイルの内容に対して grep -A 2 '"level": "Error"' コマンドを実行できます。これにより、各エラー行とその後の 2 行が表示されます。これらの行には、対応するデータベースオブジェクトの名前と、問題の修正方法に関するガイダンスが含まれています。


$ cat upgrade-prechecks.log | grep -A 2 '"level": "Error"'

"level": "Error",
"dbObject": "problematic_upgrade.dangling_fulltext_index",
"description": "Table `problematic_upgrade.dangling_fulltext_index` contains dangling FULLTEXT index. Kindly recreate the table before upgrade."

この例では、問題のあるテーブルに対して次の SQL コマンドを実行して問題を解決するか、ダングリングインデックスなしでテーブルを再作成することができます。


OPTIMIZE TABLE problematic_upgrade.dangling_fulltext_index;

次に、アップグレードを再試行します。

Aurora MySQL インプレースアップグレードのトラブルシューティング

以下のヒントを使用して、Aurora MySQL インプレースアップグレードに関する問題のトラブルシューティングを行います。これらのヒントは、Aurora Serverless DB クラスターには適用されません。

インプレースアップグレードがキャンセルされた、または遅い理由	効果	メンテナンス期間内にインプレースアップグレードを完了するためのソリューション
関連する Aurora クロスリージョンレプリカに対するパッチが未適用	Aurora はアップグレードをキャンセルします。	Aurora クロスリージョンレプリカをアップグレードして、もう一度試します。
クラスターに準備済み状態の XA トランザクションがある	Aurora はアップグレードをキャンセルします。	準備済みのすべての XA トランザクションをコミットまたはロールバックします。
クラスターはデータ定義言語 (DDL) ステートメントを処理しています	Aurora はアップグレードをキャンセルします。	すべての DDL ステートメントが終了したら、アップグレードを待って実行することをお勧めします。
クラスターの多くの行で、コミットされていない変更があります	アップグレードには長時間かかる場合があります。	アップグレードプロセスは、コミットされていない変更をロールバックします。この条件のインジケータは、`TRX_ROWS_MODIFIED` テーブル内の `INFORMATION_SCHEMA.INNODB_TRX` の値です。すべての大きなトランザクションがコミットまたはロールバックされた後にのみ、アップグレードを実行することをお勧めします。
クラスターには多数の UNDO レコードがあります	アップグレードには長時間かかる場合があります。	コミットされていないトランザクションが多数の行に影響を与えない場合でも、大量のデータが含まれる可能性があります。例えば、大きな BLOB を挿入する場合などです。Aurora は、この種のトランザクションアクティビティのイベントを自動的に検出または生成しません。この条件のインジケータは、履歴リスト (HLL) の長さです。アップグレードプロセスは、コミットされていない変更をロールバックします。 HLL は、`SHOW ENGINE INNODB STATUS` SQL コマンドからの出力で確認することも、次の SQL クエリを使用して直接確認することもできます。 `SELECT count FROM information_schema.innodb_metrics WHERE name = 'trx_rseg_history_len';` また、Amazon CloudWatch で `RollbackSegmentHistoryListLength` メトリクスをモニタリングすることもできます。 HLL の長さが短くなった後にのみ、アップグレードを実行することをお勧めします。
クラスターは、大きなバイナリログトランザクションをコミット中です	アップグレードには長時間かかる場合があります。	アップグレードプロセスは、バイナリログの変更が適用されるまで待ちます。この期間中にさらに多くのトランザクションまたは DDL ステートメントがスタートされる可能性があり、アップグレードプロセスの速度はさらに低下します。クラスターがバイナリログレプリケーションの変更を生成するためのビジー状態でない場合に、アップグレードプロセスがスケジュールされます。Aurora は、この条件のイベントを自動的に検出または生成しません。
ファイルの削除または破損によるスキーマの不一致	Aurora はアップグレードをキャンセルします。	一時テーブルのデフォルトのストレージエンジンを MyISAM から InnoDB に変更します。以下のステップを実行します。 `default_tmp_storage_engine` DB パラメータを `InnoDB` に変更します。 DB クラスターを再起動します。再起動後、`default_tmp_storage_engine` DB パラメータが `InnoDB` に設定されていることを確認します。以下のコマンドを使用します。 `show global variables like 'default_tmp_storage_engine';` MyISAM ストレージエンジンを使用する一時テーブルは作成しないでください。間もなくアップグレードを行う予定なので、データベースワークロードを一時停止し、新しいデータベース接続を作成しないことをお勧めします。インプレースアップグレードを再試行してください。
マスターユーザーが削除されました	Aurora はアップグレードをキャンセルします。	重要マスターユーザーを削除しないでください。ただし、何らかの理由でマスターユーザーを削除する必要がある場合は、次の SQL コマンドを使用して復元します。 CREATE USER 'master_username'@'%' IDENTIFIED BY 'master_user_password' REQUIRE NONE PASSWORD EXPIRE DEFAULT ACCOUNT UNLOCK; GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, RELOAD, PROCESS, REFERENCES, INDEX, ALTER, SHOW DATABASES, CREATE TEMPORARY TABLES, LOCK TABLES, EXECUTE, REPLICATION SLAVE, REPLICATION CLIENT, CREATE VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE, CREATE USER, EVENT, TRIGGER, LOAD FROM S3, SELECT INTO S3, INVOKE LAMBDA, INVOKE SAGEMAKER, INVOKE COMPREHEND ON . TO 'master_username'@'%' WITH GRANT OPTION;

アップグレードの事前チェックの失敗を起こす問題のトラブルシューティングの詳細については、以下のブログを参照してください。

以下のステップを使用して、上記の表の一部の条件に対して独自のチェックを実行できます。これにより、データベースがアップグレードを正常かつ迅速に完了できる状態にあることが分かっているときに、アップグレードをスケジュールすることができます。

XA RECOVER ステートメントを実行することで、開いている XA トランザクションを確認できます。アップグレードのスタート前に、XA トランザクションをコミットまたはロールバックできます。
SHOW PROCESSLIST ステートメントを実行し、出力でCREATE、DROP、ALTER、RENAME、および TRUNCATE ステートメントを探して、DDL ステートメントを確認できます。アップグレードのスタート前に、すべての DDL ステートメントを完了させます。
INFORMATION_SCHEMA.INNODB_TRX テーブルをクエリすることで、コミットされていない行の総数を確認できます。テーブルには、トランザクションごとに 1 つの行が含まれます。TRX_ROWS_MODIFIED 列には、トランザクションによって変更または挿入された行の数が含まれます。
InnoDB 履歴リストの長さを確認するには、SHOW ENGINE INNODB STATUS SQL ステートメントを実行し、出力で History list length を探します。次のクエリを実行して、値を直接確認することもできます。
```
SELECT count FROM information_schema.innodb_metrics WHERE name = 'trx_rseg_history_len';
```
履歴リストの長さは、マルチバージョン同時実行制御 (MVCC) の実装のためにデータベースに保存される UNDO 情報の量に対応します。

Aurora MySQL バージョン 3 のアップグレード後のクリーンアップ

Aurora MySQL バージョン 2 クラスターを Aurora MySQL バージョン 3 にアップグレードした後、次のようなその他のクリーンアップアクションを実行できます。

カスタムパラメータグループの新しい MySQL 8.0 互換バージョンを作成します。必要なカスタムパラメータ値を新しいパラメータグループに適用します。
CloudWatch アラーム、セットアップスクリプトなどを更新して、インクルーシブな言語変更の影響を受けた名前のメトリクスに、新しい名前を使用します。このようなメトリクスの一覧は、Aurora MySQL バージョン 3 に対する包括的な言語変更をご覧ください。
AWS CloudFormation テンプレートをすべて更新して、包括的な言語の変更によって影響を受けるすべてのコンフィギュレーションパラメータの名前を新しくします。そのようなパラメータのリストについては、Aurora MySQL バージョン 3 に対する包括的な言語変更を参照してください。

空間インデックス

Aurora MySQL バージョン 3 にアップグレードした後、空間インデックスに関連するオブジェクトおよびインデックスを削除または再作成する必要があるかどうかをチェックします。MySQL 8.0 より前では、Aurora は空間リソース識別子 (SRID) を含まないインデックスを使用して空間クエリを最適化できました。Aurora MySQL バージョン 3 では、SRID を含む空間インデックスのみを使用します。アップグレード中、Aurora は SRID のない空間インデックスを自動的にドロップし、警告メッセージをデータベースログに出力します。このような警告メッセージが表示された場合は、アップグレード後に SRID を使用して新しい空間インデックスを作成します。MySQL 8.0 での空間関数とデータ型の変更の詳細については、MySQL リファレンスマニュアルの「MySQL 8.0 での変更」を参照してください。

ブラウザで JavaScript が無効になっているか、使用できません。

AWS ドキュメントを使用するには、JavaScript を有効にする必要があります。手順については、使用するブラウザのヘルプページを参照してください。

ドキュメントの表記規則

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

Amazon Aurora MySQL に関するデータベースエンジンの更新と修正