Amazon Aurora MySQL DB クラスターのメジャーバージョンのアップグレード - Amazon Aurora
Aurora MySQL バージョン 2 からバージョン 3 へのアップグレード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 バージョン 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 ブルー/グリーンデプロイを使用する」を参照してください。