Amazon Aurora MySQL DB クラスターのメジャーバージョンのアップグレード - Amazon Aurora
Aurora MySQL バージョン 2 からバージョン 3 へのアップグレードAurora MySQL メジャーバージョンのアップグレードプロセスメジャーバージョンの Aurora MySQL インプレースアップグレードの仕組みAurora MySQL クラスターのメジャーバージョンアップグレードの計画

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 インスタンスが保持されます。ただし、インプレースアップグレードの所要時間は、スキーマのプロパティとクラスターのビジー状態によって異なります。したがって、クラスターのニーズに応じて、複数のアップグレード方法から選択できます。

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

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

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

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

Aurora MySQL DB クラスターのタイプ インプレースアップグレードを使用できますか? アクション

Aurora MySQL プロビジョニングクラスター、バージョン 2

可能

インプレースアップグレードは、MySQL 5.7 互換 Aurora MySQL クラスターでサポートされます。

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

Aurora MySQL プロビジョニングクラスター、バージョン 3

該当しない

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 クラスターからのものであれば、インプレースアップグレードを実行できます。バイナリログのレプリケーションが 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 つのステージがあります。

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

    Aurora で必要な条件が満たされていないことが検出された場合は、イベントの詳細に示されている条件を変更します。Aurora MySQL インプレースアップグレードのトラブルシューティング のガイダンスに従います。Aurora で、アップグレードを遅らせる原因となる条件が検出された場合は、長期間にわたりアップグレードをモニタリングすることを計画します。

  2. Aurora はクラスターをオフラインにします。次に、Aurora が前のステージと同様の一連のテストを実行し、シャットダウンプロセス中に新たな問題が発生していないことを確認します。この時点で、Aurora がアップグレードの妨げになる条件を検出した場合、Aurora はアップグレードをキャンセルし、クラスターをオンラインに戻します。この場合、条件がいつから適用されていないかを確認し、アップグレードを再度スタートします。

  3. Aurora は、クラスターボリュームのスナップショットを作成します。アップグレードの完了後に、互換性やその他の種類の問題を発見したとします。または、元のクラスターとアップグレードされたクラスターの両方を使用してテストを実行するとします。このような場合、このスナップショットから復元し、元のエンジンバージョンと元のデータを使用して新しいクラスターを作成することができます。

    ヒント

    このスナップショットは手動スナップショットです。ただし、Aurora は、手動スナップショットのクォータに達した場合でも、それを作成してアップグレードプロセスを続行することができます。このスナップショットは、削除するまで永続的に残ります (必要な場合)。アップグレード後のテストをすべて完了したら、このスナップショットを削除してストレージ料金を最小限に抑えることができます。

  4. クラスターボリュームの Aurora クローンを作成します。クローン作成は、実際のテーブルデータのコピーを伴わない高速オペレーションです。アップグレード中、Aurora に問題が発生すると、クローンが作成されたクラスターボリュームから元のデータに戻り、クラスターをオンラインに戻します。アップグレード中のクローン作成の一時ボリュームは、単一のクラスターボリュームでの通常のクローン数の制限を受けません。

  5. Aurora は、ライター DB インスタンスのクリーンシャットダウンを実行します。クリーンシャットダウン中は、以下のオペレーションの進行状況イベントが 15 分ごとに記録されます。RDS コンソールの [イベント] ページで、発生したイベントを確認できます。

    • Aurora は、古いバージョンの行の UNDO レコードを消去します。

    • Aurora は、コミットされていないトランザクションをロールバックします。

  6. Aurora は、ライター DB インスタンスのエンジンバージョンをアップグレードします。

    • Aurora は、新しいエンジンバージョンのバイナリをライター DB インスタンスにインストールします。

    • Aurora は、ライター DB インスタンスを使用して、データを MySQL 5.7 互換のフォーマットにアップグレードします。このステージでは、Aurora によってシステムテーブルが変更され、クラスターボリュームのデータに影響を与えるその他の変換が実行されます。特に、Aurora はシステムテーブル内のパーティションのメタデータをアップグレードして、MySQL 5.7 のパーティションのフォーマットとの互換性を持たせます。クラスター内のテーブルに多数のパーティションがある場合、このステージには長時間かかります。

      このステージでエラーが発生した場合は、MySQL エラーログで詳細を確認できます。このステージのスタート後に何らかの理由でアップグレードプロセスが失敗した場合、Aurora はクローンが作成されたクラスターボリュームから元のデータを復元します。

  7. Aurora は、リーダー DB インスタンスのエンジンバージョンをアップグレードします。

  8. アップグレードプロセスは完了しました。アップグレードプロセスが正常に完了したことを示す最終イベントが、Aurora により記録されます。DB クラスターが新しいメジャーバージョンで実行されています。

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

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

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 クラスターのクローン作成によるアップグレードのシミュレーション

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

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

  1. 元のクラスターのクローンを作成します。「Amazon Aurora DB クラスターのボリュームのクローン作成」 の手順に従います。

  2. 元のクラスターと同じようなライターおよびリーダー DB インスタンスのセットを設定します。

  3. クローンが作成されたクラスターのインプレースアップグレードを実行します。「インプレースアップグレードの実行手順」 の手順に従います。

    クローンを作成したら、すぐにアップグレードをスタートします。これにより、クラスターボリュームは元のクラスターと同じ状態になります。アップグレードの実行前にクローンがアイドル状態になっている場合、Aurora がバックグラウンドでデータベースのクリーンアップ処理を実行します。その場合、クローンのアップグレードは、元のクラスターのアップグレードを正確にシミュレーションしません。

  4. クローンが作成されたクラスターを使用して、アプリケーションの互換性、パフォーマンス、管理手順などをテストします。

  5. 問題が発生した場合は、それらを考慮してアップグレードの計画を調整してください。例えば、上のバージョンの特徴セットと互換性を持たせるように、任意のアプリケーションコードを適用させます。クラスター内のデータ量を基に、アップグレードにかかる時間を推定します。クラスターがビジーではない時間にアップグレードをスケジュールすることもできます。

  6. テストクラスターでアプリケーションとワークロードが適切に動作することが確認できたら、運用クラスターのインプレースアップグレードを実行します。

  7. メジャーバージョンのアップグレード中のクラスターの合計ダウンタイムを最小限に抑えます。そのためには、アップグレード時にクラスターのワークロードが低いか、0 であることを確認します。特に、アップグレードのスタート時は、進行中の長時間実行トランザクションがないことを確認してください。

ブルー/グリーンデプロイ

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