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

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

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

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

Aurora MySQL 2.x から 3.x へのアップグレード

現在、Aurora MySQL バージョン 3 にアップグレードするには、Aurora MySQL バージョン 2 クラスターのスナップショットを復元して、新しいバージョン 3 クラスターを作成する必要があります。下のクラスターが Aurora MySQL バージョン 1 を実行している場合は、まずバージョン 2 にアップグレードし、スナップショットの復元手法を使用してバージョン 3 クラスターを作成します。Aurora MySQL バージョン 3 およびアップグレード後に使用できる新機能に関する一般的な情報については、Aurora MySQL バージョン 3 は MYSQL 8.0 との互換性があります。 を参照してください。このタイプのアップグレードの詳細と例については、Aurora MySQL バージョン 3 のアップグレード計画 および Aurora MySQL バージョン 3 へのアップグレード を参照してください。

ヒント

クラスターのメジャーバージョンを 2.x から 3.x にアップグレードすると、元のクラスターとアップグレードされたクラスターの両方が engine 属性に同じ aurora-mysql 値を使用します。

Aurora MySQL 1.x から 2.x へのアップグレード

1.x から 2.x へメジャーバージョンをアップグレードすると、クラスターの engine 属性は aurora から aurora-mysql に変更されます。変更された AWS CLI 値に対応するために、このクラスターで使用する任意の engine または API オートメーションを必ず更新してください。

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

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

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

クラスターが 1.22.3 より前のバージョンで実行されている場合、Aurora MySQL は初期のステップとして 1.22.3 へのアップグレードを自動的に実行するため、アップグレードに時間がかかる場合があります。メジャーバージョンをアップグレードする際のダウンタイムを最小限に抑えるため、初期のマイナーバージョンを Aurora MySQL 1.22.3 にアップグレードできます。

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

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

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

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

注記

この手法は Aurora MySQL バージョン 1 からバージョン 2 へのアップグレードに適用されます。現在、クローンを使用して Aurora MySQL バージョン 2 から 3 にアップグレードすることはできません。

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

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

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

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

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

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

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

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

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

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

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

Aurora MySQL プロビジョニングされたクラスター、1.22.3 以降

はい

これは、最も手短なアップグレード手順です。Aurora は、初期に中間アップグレードを実行する必要はありません。

Aurora MySQL プロビジョニングされたクラスター (1.22.3 より前)

はい

クラスターが Aurora MySQL 1.22.3 以降で実行されている場合よりも、アップグレードに時間がかかる場合があります。メジャーバージョンのアップグレード中に、Aurora MySQL は、最小でも 1.22.3 のバージョンを使用して、データベースのクリーンアップを実行します。Aurora MySQL は、クリーンアップを実行する前に、初期のステップとして 1.22.3 へのアップグレードを自動的に実行します。

Aurora MySQL プロビジョニングされたクラスター、2.0 以降

いいえ

インプレースアップグレードは MySQL 5.7 との互換性を有効にするため、5.6 互換 Aurora MySQL クラスターに対してのみ行います。Aurora MySQL バージョン 2 には、既に 5.7 との互換性があります。5.7 互換バージョンから別のバージョンに変更するには、マイナーバージョンまたはパッチレベルをアップグレードする手順を使用してください。

Aurora MySQL プロビジョニングされたクラスター、3.1.0 以降

いいえ

Aurora MySQL バージョン 3 へのアップグレードの詳細については、Aurora MySQL バージョン 3 のアップグレード計画Aurora MySQL バージョン 3 へのアップグレード を参照してください。

Aurora Serverless クラスター

いいえ

5.6 互換 Aurora Serverless クラスターのスナップショットを作成します。5.7 互換のクラスターにスナップショットを復元します。新しいクラスター Aurora Serverless を作成するか、他の種類の 5.7 互換クラスターを作成するかを選択できます。

Aurora Global Database のクラスター

はい

Aurora Global Database のクラスターのインプレースアップグレード実行の手順に従います。グローバルデータベースのプライマリクラスターでアップグレードを実行します。Aurora は、グローバルデータベースのプライマリクラスター、ならびにすべてのセカンダリクラスターに対し、同時に自動アップグレードを実行します。AWS CLI または RDS API を使用する場合は、modify-global-cluster または ModifyGlobalCluster の代わりに modify-db-cluster コマンドまたは ModifyDBCluster オペレーションを呼び出します。

マルチマスタークラスター

いいえ

現在、マルチマスターレプリケーションは Aurora MySQL 5.7 互換クラスターでは使用できません。また、スナップショットの復元を実行してマルチマスタークラスターをアップグレードすることはできません。マルチマスタークラスターから Aurora MySQL 5.7 互換または 8.0 互換クラスターにデータを移動する必要がある場合は、AWS Database Migration Service (AWS DMS) などのツールまたは mysqldump コマンドによって生成された論理ダンプを使用します。

パラレルクエリクラスター

おそらく

古い Aurora MySQL バージョンを使用している既存のパラレルクエリクラスターがある場合は、まずクラスターを Aurora MySQL 1.23 にアップグレードします。「パラレルクエリのアップグレードに関する考慮事項」 の手順に従います。この初期のアップグレード後、パラレルクエリを再度有効にするには構成パラメータにいくつか変更を加えます。その後、インプレースアップグレードを実行します。この場合、Aurora MySQL バージョンに 2.09.1 以降を選択します。

バイナリログレプリケーションのターゲットのクラスター

おそらく

バイナリログのレプリケーションが 5.6 互換 Aurora MySQL クラスターからのものであれば、インプレースアップグレードを実行できます。バイナリログのレプリケーションが RDS 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 DB クラスターのメジャーバージョンをアップグレードするには

  1. (オプション) メジャーバージョンの Aurora MySQL インプレースアップグレードの仕組み で背景のマテリアルを確認します。Aurora MySQL クラスターのメジャーバージョンアップグレードの計画 の説明に従い、アップグレード前に計画とテストを実行します。

  2. AWS Management Console にサインインし、Amazon RDS コンソール (https://console.aws.amazon.com/rds/) を開きます。

  3. 元の 1.x クラスターでカスタムパラメータグループを使用した場合は、対応する MySQL 5.7 互換のパラメータグループを作成します。新しいパラメータグループの設定パラメータに必要な調整を行います。詳細については、「インプレースアップグレードはクラスターのパラメータグループにどのような影響を与えるか」を参照してください。

  4. ナビゲーションペインで、[データベース] を選択します。

  5. リストから、変更する DB クラスターを選択します。

  6. 変更を選択します。

  7. [バージョン] で、Aurora MySQL 2.x バージョンを選択します。

  8. [Continue (続行)] を選択します。

  9. 次のページで、アップグレードを実行するタイミングを指定します。[次の定期メンテナンス期間中] または [今すぐ] を選択します。

  10. (オプション) アップグレード中、RDS コンソールの [イベント] ページを定期的に確認します。これにより、アップグレードの進行状況をモニタリングし、問題を特定することができます。アップグレードで問題が発生した場合は、Aurora MySQL インプレースアップグレードのトラブルシューティング を参照してステップを実行してください。

  11. この手順のスタート時に、新しい MySQL 5.7 互換パラメータグループを作成した場合は、アップグレードしたクラスターにカスタムパラメータグループを関連付けます。詳細については、「インプレースアップグレードはクラスターのパラメータグループにどのような影響を与えるか」を参照してください。

    注記

    このステップを実行するには、クラスターを再起動して新しいパラメータグループを適用する必要があります。

  12. (オプション) アップグレード後のテストが完了したら、アップグレードのスタート時に Aurora によって作成された手動スナップショットを削除します。

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

  • --db-cluster-identifier

  • --engine aurora-mysql

  • --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 バージョン 2.09.0 にアップグレードします。アップグレードは、次のメンテナンスウィンドウを待つことなく、すぐに実行されます。

Linux、macOS、Unix の場合:

aws rds modify-db-cluster \ --db-cluster-identifier sample-cluster \ --engine aurora-mysql \ --engine-version 5.7.mysql_aurora.2.09.0 \ --allow-major-version-upgrade \ --apply-immediately

Windows の場合:

aws rds modify-db-cluster ^ --db-cluster-identifier sample-cluster ^ --engine aurora-mysql ^ --engine-version 5.7.mysql_aurora.2.09.0 ^ --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.6 または 5.7 と互換性のあるクラスターの異なる構成設定のセットがあります。インプレースアップグレードを実行する際、アップグレードされたクラスターとそのすべてのインスタンスで、対応する 5.7 互換クラスターおよびインスタンスのパラメータグループを使用する必要があります。クラスターとインスタンスでデフォルトの 5.6 互換パラメータグループを使用している場合、アップグレードされたクラスターとインスタンスはデフォルトの 5.7 互換パラメータグループでスタートされます。クラスターとインスタンスでカスタムパラメータグループを使用する場合は、対応する 5.7 互換のパラメータグループを作成し、アップグレードプロセスでそれらを指定する必要があります。

元のクラスターで 5.6 互換のカスタムクラスターのパラメータグループを使用する場合は、対応する 5.7 互換クラスターのパラメータグループを作成します。アップグレードプロセスの一環として、そのパラメータグループをクラスターに関連付けます。

同様に、対応する 5.7 互換の DB パラメータグループを作成します。アップグレードプロセスの一環として、そのパラメータグループをクラスター内のすべての DB インスタンスに関連付けます。

重要

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

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

MySQL 5.6 互換クラスターの場合、engine コマンドまたは RDS API オペレーションで AWS CLI パラメータに使用する値は aurora です。MySQL 5.7 互換クラスターないし MySQL 8.0 互換クラスターの場合、対応する値は aurora-mysql です。Aurora MySQL バージョン 1 からバージョン 2 または バージョン 3 にアップグレードする場合は、Aurora MySQL クラスターと DB インスタンスのセットアップと管理に使用するアプリケーションやスクリプトをすべて変更してください。

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

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

# Add a new DB instance to a MySQL 5.6-compatible cluster. aws rds create-db-instance --db-instance-identifier instance-2020-04-28-6889 --db-cluster-identifier cluster-2020-04-28-2690 \ --db-instance-class db.t2.small --engine aurora --region us-east-1 # Find the Aurora MySQL v1.x versions available for minor version upgrades and patching. aws rds describe-orderable-db-instance-options --engine aurora --region us-east-1 \ --query 'OrderableDBInstanceOptions[].{EngineVersion:EngineVersion}' --output text # Check the default parameter values for MySQL 5.6-compatible clusters. aws rds describe-db-parameters --db-parameter-group-name default.aurora5.6 --region us-east-1

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

# Add a new DB instance to a MySQL 5.7-compatible cluster. aws rds create-db-instance --db-instance-identifier instance-2020-04-28-3333 --db-cluster-identifier cluster-2020-04-28-2690 \ --db-instance-class db.t2.small --engine aurora-mysql --region us-east-1 # Find the Aurora MySQL v2.x versions available for minor version upgrades and patching. aws rds describe-orderable-db-instance-options --engine aurora-mysql --region us-east-1 \ --query 'OrderableDBInstanceOptions[].{EngineVersion:EngineVersion}' --output text # 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

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

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

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

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


        グローバルデータベースクラスターをアップグレードする

AWS CLI または RDS API を使用する場合は、modify-global-cluster コマンドまたは ModifyGlobalCluster オペレーションを呼び出して、アップグレードプロセスをスタートします。modify-db-clusterModifyDBCluster は使用しません。

注記

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

アップグレード後

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

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

Aurora MySQL インプレースアップグレードのトラブルシューティング
インプレースアップグレードがキャンセルされた、または遅い理由 メンテナンス期間内にインプレースアップグレードを完了するためのソリューション
クラスターに準備済みステートメントの XA トランザクションがある Aurora はアップグレードをキャンセルします。 準備済みのすべての XA トランザクションをコミットまたはロールバックします。
クラスターはデータ定義言語 (DDL) ステートメントを処理しています Aurora はアップグレードをキャンセルします。 すべての DDL ステートメントが終了したら、アップグレードを待って実行することをお勧めします。
クラスターの多くの行で、コミットされていない変更があります アップグレードには長時間かかる場合があります。 アップグレードプロセスは、コミットされていない変更をロールバックします。この条件のインジケータは、TRX_ROWS_MODIFIED テーブル内の INFORMATION_SCHEMA.INNODB_TRX の値です。すべての大きなトランザクションがコミットまたはロールバックされた後にのみ、アップグレードを実行することをお勧めします。
クラスターには多数の UNDO レコードがあります アップグレードには長時間かかる場合があります。 コミットされていないトランザクションが多数の行に影響を与えない場合でも、大量のデータが含まれる可能性があります。例えば、大きな BLOB を挿入する場合などです。Aurora は、この種のトランザクションアクティビティのイベントを自動的に検出または生成しません。この条件のインジケータは、履歴リストの長さです。アップグレードプロセスは、コミットされていない変更をロールバックします。履歴リストの長さが短くなった後にのみ、アップグレードを実行することをお勧めします。
クラスターは、大きなバイナリログトランザクションをコミット中です アップグレードには長時間かかる場合があります。 アップグレードプロセスは、バイナリログの変更が適用されるまで待ちます。この期間中にさらに多くのトランザクションまたは DDL ステートメントがスタートされる可能性があり、アップグレードプロセスの速度はさらに低下します。クラスターがバイナリログレプリケーションの変更を生成するためのビジー状態でない場合に、アップグレードプロセスがスケジュールされます。Aurora は、この条件のイベントを自動的に検出または生成しません。

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

  • XA RECOVER ステートメントを実行することで、開いている XA トランザクションを確認できます。アップグレードのスタート前に、XA トランザクションをコミットまたはロールバックできます。

  • SHOW PROCESSLIST ステートメントを実行し、出力でCREATEDROPALTERRENAME、および 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 インプレースアップグレードのチュートリアル

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

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

$ aws rds create-db-cluster --db-cluster-identifier cluster-56-2020-11-17-3824 --engine aurora \ --db-cluster-version 5.6.mysql_aurora.1.22.3 ... $ aws rds create-db-instance --db-instance-identifier instance-2020-11-17-7832 \ --db-cluster-identifier cluster-56-2020-11-17-3824 --db-instance-class db.t2.medium --engine aurora ... $ aws rds wait db-instance-available --db-instance-identifier instance-2020-11-17-7832 --region us-east-1

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

$ aws rds describe-db-clusters --db-cluster-identifier cluster-56-2020-11-17-9355 \ --query '*[].{EngineVersion:EngineVersion}' --output text 5.6.mysql_aurora.1.22.3 $ aws rds describe-db-engine-versions --engine aurora --engine-version 5.6.mysql_aurora.1.22.3 \ --query '*[].[ValidUpgradeTarget]' [ [ [ { "Engine": "aurora-mysql", "EngineVersion": "5.7.mysql_aurora.2.07.3", "Description": "Aurora (MySQL 5.7) 2.07.3", "AutoUpgrade": false, "IsMajorVersionUpgrade": true } ] ] ]

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

$ aws rds modify-db-cluster --db-cluster-identifier cluster-56-2020-11-17-9355 \ --engine-version 5.7.mysql_aurora.2.04.9 --region us-east-1 --apply-immediately An error occurred (InvalidParameterCombination) when calling the ModifyDBCluster operation: Cannot find upgrade target from 5.6.mysql_aurora.1.22.3 with requested version 5.7.mysql_aurora.2.04.9. $ aws rds modify-db-cluster --db-cluster-identifier cluster-56-2020-11-17-9355 \ --engine-version 5.7.mysql_aurora.2.09.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 cluster-56-2020-11-17-9355 \ --engine-version 5.7.mysql_aurora.2.09.0 --region us-east-1 --apply-immediately --allow-major-version-upgrade { "DBClusterIdentifier": "cluster-56-2020-11-17-9355", "Status": "available", "Engine": "aurora", "EngineVersion": "5.6.mysql_aurora.1.22.3" }

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

$ aws rds describe-db-clusters --db-cluster-identifier cluster-56-2020-11-17-9355 \ --query '*[].[Status,EngineVersion]' --output text upgrading 5.6.mysql_aurora.1.22.3 $ aws rds describe-db-instances --db-instance-identifier instance-2020-11-17-5158 \ --query '*[].{DBInstanceIdentifier:DBInstanceIdentifier,DBInstanceStatus:DBInstanceStatus} | [0]' { "DBInstanceIdentifier": "instance-2020-11-17-5158", "DBInstanceStatus": "upgrading" } $ aws rds wait db-instance-available --db-instance-identifier instance-2020-11-17-5158

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

$ aws rds describe-db-clusters --region us-east-1 --db-cluster-identifier cluster-56-2020-11-17-9355 \ --query '*[].[EngineVersion]' --output text 5.7.mysql_aurora.2.09.0

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

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

$ aws rds describe-db-clusters --region us-east-1 --db-cluster-identifier cluster-56-2020-11-17-3824 \ --query '*[].{EngineVersion:EngineVersion}' --output text 5.6.mysql_aurora.1.22.2 $ aws rds describe-db-engine-versions --engine aurora --engine-version 5.6.mysql_aurora.1.22.2 \ --query '*[].[ValidUpgradeTarget]|[0][0]|[*].[EngineVersion,IsMajorVersionUpgrade]' --output text 5.6.mysql_aurora.1.22.3 False 5.6.mysql_aurora.1.23.0 False 5.6.mysql_aurora.1.23.1 False 5.7.mysql_aurora.2.07.1 True 5.7.mysql_aurora.2.07.1 True 5.7.mysql_aurora.2.07.2 True 5.7.mysql_aurora.2.07.3 True 5.7.mysql_aurora.2.09.1 True $ aws rds modify-db-cluster --db-cluster-identifier cluster-56-2020-11-17-9355 \ --engine-version 5.7.mysql_aurora.2.09.0 --region us-east-1 --no-apply-immediately --allow-major-version-upgrade ...

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

$ aws rds describe-db-clusters --db-cluster-identifier cluster-56-2020-11-17-9355 --region us-east-1 --query '*[].[PreferredMaintenanceWindow]' [ [ "sat:08:20-sat:08:50" ] ] $ aws rds modify-db-cluster --db-cluster-identifier cluster-56-2020-11-17-3824 --preferred-maintenance-window tue:10:00-tue:10:30" $ aws rds describe-db-clusters --db-cluster-identifier cluster-56-2020-11-17-3824 --region us-east-1 --query '*[].[PreferredMaintenanceWindow]' [ [ "tue:10:00-tue:10:30" ] ]
$ aws rds create-db-cluster --engine aurora --db-cluster-identifier cluster-56-2020-11-17-9355 \ --region us-east-1 --master-username my_username --master-user-password my_password { "DBClusterIdentifier": "cluster-56-2020-11-17-9355", "DBClusterArn": "arn:aws:rds:us-east-1:123456789012:cluster:cluster-56-2020-11-17-9355", "Engine": "aurora", "EngineVersion": "5.6.mysql_aurora.1.22.2", "Status": "creating", "Endpoint": "cluster-56-2020-11-17-9355.cluster-ccfbt21ixr91.us-east-1-integ.rds.amazonaws.com", "ReaderEndpoint": "cluster-56-2020-11-17-9355.cluster-ro-ccfbt21ixr91.us-east-1-integ.rds.amazonaws.com" } $ aws rds create-db-instance --db-instance-identifier instance-2020-11-17-5158 \ --db-cluster-identifier cluster-56-2020-11-17-9355 --db-instance-class db.r5.large --region us-east-1 --engine aurora { "DBInstanceIdentifier": "instance-2020-11-17-5158", "DBClusterIdentifier": "cluster-56-2020-11-17-9355", "DBInstanceClass": "db.r5.large", "DBInstanceStatus": "creating" } $ aws rds wait db-instance-available --db-instance-identifier instance-2020-11-17-5158 --region us-east-1

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

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

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

古いクラスターからアップグレードされたクラスターへの即時の切り替えが最優先事項である場合、古いクラスターと新しいクラスターを side-by-side 実行するマルチステッププロセスを使用できます。この場合、新しいクラスターが引き継ぐ準備ができるまで、古いクラスターから新しいクラスターにデータをレプリケートします。詳細については、ブログ記事: Performing major version upgrades for Amazon Aurora MySQL with minimum downtime を参照してください。