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