Amazon Aurora MySQL バージョン 3（MySQL 8.0 互換）へのアップグレード

Amazon Aurora MySQL 互換エディションバージョン 3 (MySQL 8.0 互換) は、Amazon Aurora MySQL でサポートされている最新バージョンのメジャーバージョンです。Amazon Aurora MySQL バージョン 3 を使用することで、最新の MySQL 互換機能とパフォーマンス向上を利用できます。MySQL 8.0 では JSON 関数、ウィンドウ関数、共通テーブル式 (CTE)、ロールベースの権限など、いくつかの新機能が導入されています。また、Amazon Aurora MySQL 3 には、Amazon Aurora Serverless v2、Amazon Aurora ゼロ ETL、AWS Graviton3 サポート、拡張バイナリログ、Amazon Aurora I/O 最適化などの新機能のサポートも含まれています。機能の完全なリストは、MySQL 8.0 と互換性のある Aurora MySQL バージョン 3 を参照してください。

Amazon Aurora MySQL の新しいメジャーバージョンがリリースされたとき、DB クラスターをいつ、どのようにアップグレードするかを選択できます。メジャーエンジンバージョンのアップグレードにより、既存のアプリケーションと下位互換性のない変更が導入される可能性があるため、データベースのバージョンをアップグレードし、メリットを最大化するための一般的な課題とベストプラクティスを認識しておくことが不可欠です。

この投稿では、アップグレードの準備をするにあたって始めるフレームワークについて説明し、標準サポートの終了タイムラインを確認した後、アップグレードプロセスの詳細について説明します。Aurora のアップグレードの事前チェック、全体的な手順、Aurora MySQL クラスターを変更するために使用できるさまざまなオプションから始めます。この投稿では、本番データベースクラスターをアップグレードする前のパフォーマンステストのベストプラクティス、変更が行われる際の監視手法、およびその他の重要な考慮事項についても説明します。

メジャーバージョンアップグレードの準備

メジャーバージョンのアップグレードを計画する際、データベースとアプリケーションの機能が期待どおりであることを確認するための一連のテストと検証ステップを定義することから始めることができます。メジャーバージョンアップグレードの要件と成功基準を考える際、このトピックをより小さな目的に分解することが役立ちます。計画に構造を与えるためのいくつかの重要な焦点領域は以下のとおりです:

互換性 – アップグレード後もクライアントアプリケーションが正しく動作することを確認します。アプリケーションが期待通りに動作し続けるために必要なプラットフォーム、データベース、クエリレベルの機能を特定します。本番環境へのアップグレード前に、互換性の問題を特定するためにアップグレードプロセスのテストを行います。テスト方法については、アップグレード前の新しい Aurora バージョンでの DB クラスタのテストを参照してください。
パフォーマンス – 本番データベースのアップグレード前のパフォーマンステストには、アプリケーションのパフォーマンスを適切に維持することと、期待される改善を検証することが含まれます。この投稿では、MySQL 5.7 と MySQL 8.0 間の変更によって導入される可能性のある違いがあるため、クエリパフォーマンスをテストするための推奨事項とツールについて説明します。
可用性 – 可用性には 2 つの重要な側面があります。1 つ目はアプリケーションのダウンタイムを最小限に抑えること、2 つ目は問題が発生した場合のフォールバックオプションを用意することです。許容できるダウンタイムとアップグレードプロセスをどの程度制御したいかに応じて、この投稿で説明する複数のアップグレードオプションから選択できます。
工数 – メジャーバージョンアップグレードの準備中は、本番環境での変更の前に非本番環境でアップグレードの計画とテストに必要なエンジニアリングの工数も見積もる必要があります。準備ステップのコストと工数を評価する際は、その作業が他の場所で再利用できるかどうかを考慮してください。適切な変更管理手順の作成に投資することで、その作業を他の状況で再利用できる可能性が高くなります。

アップグレードのタイムライン

Amazon Aurora MySQL バージョン 2(MySQL 5.7 互換)は、2024 年 10 月 31 日に標準サポートが終了します。詳細な手順については、Amazon Aurora MySQL 互換エディションバージョン 2 の標準サポート終了の準備を参照してください。

標準サポートの終了タイムライン

標準サポート期間終了に向けた主な日程は以下のとおりです。

2024 年 10 月 31 日まで – Amazon Aurora MySQL バージョン 2(MySQL 5.7 互換)から Amazon Aurora MySQL バージョン 3(MySQL 8.0 互換)へのクラスターのアップグレードができます。
2024 年 10 月 31 日 – この日に、Aurora MySQL バージョン 2 が標準サポートの提供終了となります。Aurora や RDS の標準サポート提供終了日から最大 3 年間、既存のバージョンを使用し続けることができるよう、Amazon RDS 延長サポートにオプトインできます。

Amazon RDS 延長サポート

2023 年 9 月、AWS はAmazon RDS 延長サポートを発表しました。これは、Amazon Relational Database Service(Amazon RDS)が、Amazon Aurora MySQL またはAmazon RDS for MySQLのメジャーバージョンに対して、Aurora または RDS の標準サポート終了日から最大 3 年間、重要なセキュリティおよびバグ修正を提供する有償のサービスです。詳細については、Amazon Aurora および Amazon RDS 上の MySQL データベース向け Amazon RDS延長サポートのご紹介およびAurora の料金の Amazon RDS延長サポートのコストを参照してください。

Aurora バージョンのリリース日とサポート終了日の更新されたタイムラインの詳細については、Amazon Aurora メジャーバージョンと Amazon Aurora マイナーバージョンを参照してください。

ターゲットバージョンの選択

Amazon Aurora MySQL 2 クラスタを Amazon Aurora MySQL 3 にアップグレードすることを検討する際、アップグレードの対象バージョンとして選択できるマイナーバージョンが複数あることに気づくかもしれません。本ブログ執筆時点で、最新の Amazon Aurora MySQL バージョンは MySQL 8.0.32 と互換性のある Amazon Aurora MySQL 3.05 です。 Aurora MySQL 3 は長期サポート(LTS) バージョンもサポートしています。これは MySQL 8.0.28 と互換性のある Aurora MySQL 3.04 マイナーバージョンです。 LTS リリースを利用しているデータベースクラスタは、そのリリースが利用可能になってから少なくとも 3 年間は同じマイナーバージョンのままでいられるため、クラスタのアップグレードサイクルを少なくすることができます。 Aurora MySQL 3 へのアップグレード時にはLTS リリースを使用するのではなく、最新のデフォルトマイナーバージョンにアップグレードして、最新の機能とバグ修正を利用することをおすすめします。バージョンごとの機能と改善点については、Amazon Aurora MySQL 3 のリリースノート Database engine updates for Amazon Aurora MySQL version 3 をご覧ください。

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

データベースエンジンのメジャーバージョンをアップグレードする際、既存のアプリケーションとの互換性を新しいバージョンとその機能の両方で確認することが、アップグレードの全体的な成功において重要な役割を果たします。MySQL データベースのバージョンとリリースごとにアプリケーションとの動作や対話方法が異なる場合があり、これによりアプリケーションの動作に変更が生じる可能性があります。

MySQL 8.0 には MySQL 5.7 と比較して多くの変更が含まれています。例えば、以前は予約されていなかった一部のキーワード(RANGE など)が MySQL 8.0 では予約されている可能性があります。また、一部の機能 (クエリキャッシュなど) が MySQL 8.0 で削除されている可能性があります。これらの違いはアップグレード中に対処する必要がある場合があります。ベストプラクティスとして、MySQL 8.0 の新機能を詳しく調べ、すべての変更を参照し、それらがワークロードに適用されるかどうかを確認することをおすすめします。特に Amazon Aurora MySQL の場合は、「Aurora MySQL バージョン 2 と Aurora MySQL バージョン 3 の比較」を参照して、アップグレード時の変更点を確認することもできます。

AWS Management Console や AWS Command Line Interface(AWS CLI) から Aurora MySQL 2 から Aurora MySQL 3 へのアップグレードを開始すると、Aurora はバックグラウンドで自動的に事前チェックを実行して、非互換性を検出します。これらの事前チェックは必須で、スキップできません。コミュニティ版 MySQL に含まれるものと、Aurora が導入したものの両方のチェックが含まれます。詳細については、Aurora MySQL のメジャーバージョンアップグレードの事前チェックを参照してください。事前チェックはアップグレードのために DB インスタンスが停止する前に実行されるため、実行している間はダウンタイムは発生しません。事前チェックで非互換性が見つかった場合、Aurora は自動的にアップグレードをキャンセルし、データベースのダウンタイムを発生させず、5.7 互換のライターインスタンスへの変更も行いません。

Aurora は、Amazon RDS コンソールのログとイベントセクションと upgrade-prechecks.log ファイルの両方で、非互換性についてイベントを生成します。 errorCount がゼロでない場合、アップグレードが成功しなかったことを示しています。ほとんどの場合、ログエントリには問題を修正するための MySQL ドキュメントへのリンクが含まれています。アップグレードを妨げる可能性のあるサンプルのシナリオとその解決策については、Aurora MySQL バージョン 3 のアップグレードのトラブルシューティングで説明されています。 upgrade-prechecks.log は、Amazon RDS コンソールのログとイベントセクションで見つけることができます。また、aws rds describe-db-log-files に続けて aws rds download-db-log-file-portion を使用することで、AWS CLI を使用することもできます。

アップグレードを開始する前に、コミュニティエディションの MySQL プリチェッカーツールを使用して既存の Aurora MySQL データベースを分析し、潜在的なアップグレードの問題の大部分を特定するためのアドホックテストを実行することもできます。

ベストプラクティスとして、本番環境でアップグレードする前に、アップグレードプロセスのテストを行うことをおすすめします。テスト方法については、アップグレード前に新しい Aurora バージョンで DB クラスターをテストするを参照してください。これらのテストを実行することで、Aurora の事前チェックログファイルを使用して、アップグレードの非互換性 (存在する場合) を把握できるだけでなく、事前チェックの実行にかかる時間とアップグレード全体の期間の見積もりが得られます。アップグレードにかかる期間は、ワークロードとデータベースオブジェクトの数によって異なります。

最後に、Aurora の事前チェックは、プロシージャ定義内の予約語など、データベースオブジェクトの非互換性をチェックします。アプリケーション側のロジックは検証しないため、予約語やサポート外の構文がアプリケーションにどのような影響を与えるかを確認する必要があります。アップグレードする前に、すべての機能が新しいバージョンで正しく動作することを確認するために、アプリケーションのテストを十分に行うことを強くおすすめします。

全体的なアップグレードプロセス

Amazon Aurora MySQL は、次のフローチャートに示すように、マルチステージのプロセスとしてメジャーバージョンアップグレードを実行します。

Aurora MySQL クラスターのバージョン 2.x からのアップグレードを開始すると、Aurora はまず、前述した対象バージョンとの互換性の問題を特定するための事前チェックを実行します。次にアップグレードに問題がある場合にロールバックできるように、事前アップグレードスナップショットを作成します。データベースは再起動され、データベースに長時間実行されるトランザクションや高い InnoDB History List Length があった場合、このステップで Undo ログがパージされます。MySQL 8 はデータディクショナリの新しい実装を導入するため、データベースオブジェクトは変更に応じて変換され、クラスターのライターインスタンスが最初にアップグレードされた後、リーダーインスタンスがアップグレードされます。詳細については、データディクショナリのアップグレード方法と Aurora MySQL のインプレースメジャーバージョンアップグレードの仕組みを参照してください。

Amazon Aurora MySQL のメジャーバージョンアップグレードの実行

ここまでで背景を確認したので、クラスターを Amazon Aurora MySQL 3 へメジャーバージョンアップグレードする手順について説明します。Amazon Aurora MySQL では、コンソール、AWS CLI、Amazon RDS API を介して DB クラスターを変更することで、メジャーバージョンアップグレードを手動で開始できます。アップグレード中はアプリケーションのダウンタイムが必要になります。Aurora はクラスター全体のエンジンバージョンをアップグレードするため、ライターとリーダーの DB インスタンスのアップグレードが同時に実行されます。ベストプラクティスとして、アップグレードを開始する前に手動スナップショットを作成して、ロールバック計画を立てることができます。このセクションでは、簡単な順に次のアップグレードオプションをカバーします。

インプレースアップグレード
Amazon RDS ブルー/グリーンデプロイメント
スナップショットリストアと Aurora クローン

インプレースアップグレード

これは最も単純なオプションで、クラスター自体でアップグレードプロセスを実行できます。これは新しいクラスターを作成しません。この手法では、すべてのデータを新しいクラスターボリュームにコピーする必要がないため、同じクラスターエンドポイントとクラスターのその他の特性が維持されます。Aurora がインプレースアップグレードを実行している間、クラスターはダウンタイムを観測します。注意が必要な点は、アップグレードプロセスを途中でキャンセルできず、アップグレードが成功または失敗するまで実行され続けることです。アップグレードプロセス中に問題が発生した場合、Aurora は変更をロールバックしようとします。詳細については、Aurora MySQL のインプレースメジャーバージョンアップグレードの仕組みを参照してください。

このオプションは本番環境のアップグレードに使用できますが、アップグレード期間中はダウンタイムが発生します。設定が簡単なため、本番で実行する前にアップグレードプロセスをテストすることもできます。インプレースアップグレードを実行する手順の詳細は、インプレースアップグレードの実行方法を参照してください。トラブルシューティングのヒントについては、Aurora MySQL のインプレースアップグレードのトラブルシューティングを参照してください。

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

データベースのアップグレード中のダウンタイムを最小限に抑えることが最優先事項である場合は、古いクラスタとアップグレードされた新しいクラスタを並行して実行するマネージドプロセスを使用できます。 Amazon RDS のブルー/グリーンデプロイメントを使用すると、新しいクラスタを引き継ぐ準備が整うまで、古いクラスタから新しいクラスタへデータをレプリケートできます。この機能を使用して、データベースクラスタをアップグレードし、ダウンタイムを最小限に抑え、リスクの低いアップグレードを実現できます。ブルー/グリーンデプロイメントは、現在の本番環境であるブルー環境と、ステージング環境であるグリーン環境の 2 つのデータベース環境で構成されます。これらは、MySQL バイナリログレプリケーションを使用して同期されています。したがって、Aurora MySQL DB クラスタのブルー/グリーンデプロイメントを作成する前に、クラスタはバイナリロギング(binlog_format) が有効になっているカスタム DB クラスタパラメータグループに関連付ける必要があります。まだ有効になっていない場合、この変更にはブルークラスタの再起動が必要です。ブルー/グリーンデプロイメントの作成手順については、ブルー/グリーンデプロイメントの作成を参照してください。

グリーン環境でメジャーまたはマイナー DB エンジンバージョンのアップグレードなどの変更を、ブルー環境に影響を与えることなく行うことができます。グリーン環境でアップグレードをテストした後、スイッチオーバーを実行して、グリーン環境をプロモートできます。スイッチオーバーのタイムアウトは 30-3,600 秒(1 時間)を指定できます。スイッチオーバーが成功すると、Amazon RDS はグリーン環境のエンドポイントの名前をブルー環境の対応するエンドポイントと一致するようにリネームするため、アプリケーションの変更は必要ありません。スイッチオーバーが成功したことを確認するには、ブルー/グリーンデプロイのベストプラクティスを参照してください。詳細な手順を含むデモを見るには、RDS ブルー/グリーンデプロイを使用した Amazon Aurora MySQL バージョン 3 へのアップグレードを参照してください。

スナップショットの復元と Aurora のクローン

開発/テスト環境のアップグレードなど、アップグレード中のダウンタイムをある程度許容できるユースケースでは、スナップショットの復元や Aurora クローンを使用できます。これは、データベースのパフォーマンスとアプリケーションの互換性の観点からメジャーバージョンアップグレードをテストするためのテスト環境を作成する際に役立つことがよくあります。

はじめに、アップグレードしたいクラスタの手動スナップショットを作成します。スナップショットを取得する前に、現在のクラスタへの書き込みワークロードを停止することにしても構いません。次に、スナップショットからリストアし、リストア中にアップグレードしたいターゲットエンジンバージョンを選択します。アップグレードはリストアプロセスの一部として実行されます。アップグレードが完了し、アップグレードされたクラスタが利用可能になったら、すべてのクライアントトラフィックを新しくアップグレードされたクラスタにリダイレクトします。ワークロードを再び有効にする前に、新しいクラスタで必要なすべての設定とカスタマイズが適用されていることを確認してください。不要になったときに元のクラスタを削除できます。

大規模なデータセットの場合、Aurora が 3 つのアベイラビリティーゾーンに分散したストレージクラスターボリュームを構築するため、リストア時間が増加することがあります。Aurora クローンは、より高速でコスト効率の高いオプションです。書き込みワークロードを停止し、オリジナルのクラスタのAurora クローンを作成できます。クローンが利用可能になったら、クローンデータベースでメジャーバージョンアップグレードを実行するために、インプレースアップグレード(前述の通り)を実行できます。アップグレードが完了し、クラスタが利用可能になったら、アプリケーショントラフィックをアップグレードされたクラスタにリダイレクトできます。

スナップショットの取得やクローンの作成前に書き込みを停止するため、どちらのオプションでもダウンタイムが発生します。加えて、新しいクラスタが作成されます。これは、クラスタに新しいエンドポイントが割り当てられ、アプリケーションコードをアップグレードされた新しいクラスタを指すように更新する必要があることを意味します。

メジャーバージョンアップグレード方法の概要

次の表はアップグレードオプションの概要を示しています。

方法	メリット	デメリット
インプレースアップグレード	直感的で便利同じデータベースエンドポイントを維持	アップグレード期間中のダウンタイム
RDS ブルー/グリーンデプロイメント	マネージド機能効率的リスクとダウンタイムの軽減ブルーとグリーンの環境を同期エンドポイントは自動的に更新	まだ有効になっていない場合、再起動を必要とするバイナリロギングを有効にする必要があります。さらに、新しいグリーン環境を作成するため、追加コストが発生します。スイッチオーバーが実行された後、前のブルークラスタを削除してコストを節約できます。
スナップショットリストア	アップグレードのテストや本番環境でのアップグレードに使用	新しいクラスタのリストアとアップグレードにかかる時間のダウンタイム
クローン	スナップショットのリストアよりも高速	クローンでインプレースアップグレードを実行するためにかかる時間のダウンタイム

最後に、ロールバックオプションを含む手動のブルー/グリーンデプロイメントを設定するという選択肢もあります。

本番環境のアップグレード前のテスト環境のパフォーマンステスト

テスト環境をアップグレードした後、本番環境でアップグレードを実施する前に、データベースのパフォーマンスを監視およびテストすることが重要です。通常、クエリ実行エンジンはバージョンアップごとに改善されますが、まれに新しいバージョンでクエリが最適ではない実行プランを使用する場合があります。 MySQL 5.7 と MySQL 8.0 の変更 (たとえば、新しいデータディクショナリなど) によってクエリパフォーマンスの違いが観察される可能性があります。これらのパフォーマンスの不一致を診断するための推奨事項を以下に示します。

Aurora クラスタの過去のパフォーマンスデータを保存し、ベースラインを確立することをおすすめします。このデータを使用して、現在のパフォーマンスを過去の傾向と比較できます。また、通常のパフォーマンスパターンと異常を区別し、問題に対処する手法を考案できます。
Aurora MySQL 2 クラスタからサンプルワークロードをキャプチャし、バージョン 3 でのパフォーマンス変更を確認するために Aurora MySQL 3 で再実行します。mysqlslap のようなツールを使用して、ブルートフォーステストのためにワークロードを再生できます。ただし、同じパラメータで同一のクエリを再実行するため、結果は異なる可能性があり、追加の検証が必要になる場合があります。
sysbench を使用して Aurora パフォーマンスを評価できます。詳細については、Amazon Aurora パフォーマンスアセスメントテクニカルガイドを参照してください。このガイドは sysbench を使用してパフォーマンスを評価していますが、bash スクリプトを調整することで、使用するツールを変更できます。
Amazon RDS Performance Insights を使用して、データベースの負荷、上位 SQL クエリ、ユーザー、待機イベントを評価します。データベース負荷が Amazon Aurora MySQL 待機イベントにどのように影響しているかを監視します。これは、パフォーマンスのボトルネックを特定するための最も重要なツールの 1 つになります。
実行に長時間かかるクエリを見つけて、最適化の対象とするために、Aurora MySQL スロークエリログを有効にすることを検討してください。
メジャーバージョンアップグレードによって、クエリの実行計画が変更される可能性があります。違いを比較するために、古いバージョンと新しいバージョンからサンプル実行計画を収集できます。さらに、以前のバージョンで force index などの最適化ヒントを使用しているクエリを確認します。これらは、メジャーバージョンアップグレード後に異なる動作をする可能性があります。Performance Insights とスロークエリログを使用して、データベースの待機に最も貢献している上位 SQL を特定した後、これらのツールの一部を使用してクエリを最適化できます。
- EXPLAIN を使用すると、クエリの実行に関連する個々のステップが表示されます。
- クエリプロファイリングは、現在のセッションで実行されているステートメントのリソース使用状況を示します。
- ANALYZE TABLE はテーブルとインデックスの統計を更新します。これにより、オプティマイザがクエリを実行するのに適切なプランを選択できます。
コミュニティ版 MySQL 8.0 と Amazon Aurora MySQL 3 からクエリキャッシュが削除されています。Aurora MySQL 2 クラスタでクエリキャッシュを使用している場合は、この変更がデータベースのパフォーマンス (SelectLatency などのメトリクス) にどのような影響を与えるかを確認してください。
MySQL 8.0 コミュニティエディションは一時テーブルを以前の MySQL バージョンとは異なる方法で処理します。この動作の変更は、Amazon Aurora MySQL 3 でも反映されています。ワークロードで多数の一時テーブルが作成される場合は、変更とその影響を確認してください。詳細は、Aurora MySQL バージョン 3 の新しい一時テーブルの動作を参照してください。
MySQL 8.0 コミュニティエディションのデフォルト文字セットは utf8mb4 であり、Aurora MySQL 3 でも同様です。アップグレード前に文字セットで必要な変更を確認してください。照合順序の競合のためにテーブルインデックスを使用できない場合、一部のクエリとストアドプロシージャのパフォーマンスが低下する可能性があります。
2 つのバージョン間のパフォーマンスを比較しているため、パフォーマンス関連パラメータのデフォルト値の変更を確認します。これは、問題を隔離および絞り込むのに役立つステップです。詳細については、変更されたサーバーのデフォルトを参照してください。

モニタリングとアラート

アップグレードを開始したら、DB インスタンスのヘルスを監視する方法や、アップグレード中のエラーをチェックする方法を確認しましょう:

アップグレードの現在のステータスは、Aurora イベントを監視することで確認できます。アップグレードのステータスを通知するには、DB インスタンスイベントのアップグレードに対応する RDS イベント ID を購読できます。
Amazon CloudWatch の CPUUtilization や FreeableMemory などのメトリクスを使用して、アップグレード後のリソース消費や、SelectLatency、CommitLatency などのクエリレイテンシーメトリクスへの影響を監視できます。メトリクスの完全なリストは、Amazon Aurora の Amazon CloudWatch メトリクスを参照してください。CloudWatch アラームを使用して、メトリクスが指定したしきい値を超えた場合に通知を受け取り、問題をトラブルシューティングできます。
Aurora アップグレードでは、初期ステップには Aurora によるクリーンシャットダウンと、トランザクションロールバックや UNDO パージなどの未完了操作の完了が含まれます。したがって、本番環境でアップグレードを開始する準備をする際には、アップグレード期間に影響を与える可能性のある長時間実行されるトランザクションがデータベースにないことを確認してください。同様に、高いロールバックセグメント履歴の長さは、Aurora がターゲットバージョンへのアップグレード前に UNDO ログをパージするため、アップグレードプロセスが遅くなる可能性があります。確認するには、次のコマンドを使用できます:
- ```
SHOW ENGINE INNODB STATUS
```
- ```
SHOW FULL PROCESSLIST
```
- ```
SELECT NAME,COUNT FROM INFORMATION_SCHEMA.INNODB_METRICS WHERE NAME="trx_rseg_history_len";
```

Amazon Aurora MySQL は、クラスタの起動とシャットダウンでエラーが発生した場合に mysql-error.log ファイルを書き込みます。ログファイルにはタイムスタンプもあり、ログエントリが書き込まれた時刻を判断できます。アップグレード中に問題が発生した場合は、ログを確認できます。詳細については、Aurora MySQL エラーログを参照してください。
アップグレードが何らかの理由で失敗した場合は、mysql-error.logファイルを確認して、問題をトラブルシューティングできます。エラーがアップグレードの事前チェック中に発生した場合は、upgrade-prechecks.log ファイルでエラーと解決手順を確認してください。

主な考慮事項

Amazon Aurora MySQL 5.7 から 8.0 へのアップグレード時には、次の重要な点を考慮する必要があります。

メジャーバージョンアップグレード時にカスタムパラメータグループが指定されていない場合、Aurora はターゲットのアップグレードバージョン用に自動的に新しいパラメータグループを作成します。カスタムパラメータグループを使用している Amazon Aurora MySQL インスタンスの場合は、アップグレード時に、現在のバージョンパラメータグループと同様のパラメータを持つターゲットバージョンのパラメータグループを常に選択してください。パラメータの変更については、Aurora MySQL バージョン 3 のパラメータ変更を参照してください。
lower_case_table_names パラメータにカスタム値を使用している場合は、この設定をあらかじめカスタムパラメータグループで設定する必要があります。Amazon Aurora MySQL バージョン 2 からバージョン 3 へのアップグレード時には、lower_case_table_names に同じ設定を使用することをおすすめします。MySQL 5.7 とは異なり、MySQL 8.0 はアップグレード後に lower_case_table_names の値を変更することが制限されます。アプリケーションの要件を確認し、設定する値を決定してください。これを後から変更することはできません。
Amazon Aurora グローバルデータベースを使用している場合は、グローバルデータベースのインプレースメジャーアップグレードのステップを確認してください。
Aurora Serverless v1 を使用している場合は、ダウンタイムを最小限に抑えて Aurora Serverless v1 から v2 へアップグレードするを参照してください。
Aurora クラスタに大量のデータベースオブジェクト(テーブル、データベース、イベント、トリガー、ストアドプロシージャなど)が含まれている場合は、インスタンスクラスを大きくすることで、アップグレードをより高速に完了できるように CPU 容量とメモリリソースを増やすことを検討してください。

結論

この投稿では、Amazon Aurora MySQL 3 のアップグレード手順、異なるアップグレードプロセス、ベストプラクティスを確認しました。 Amazon Aurora MySQL 2.x クラスタをアップグレードし、最新バージョンで利用できる新機能と最適化を活用するために必要なテストを実行することをおすすめします。

アップグレードの詳細については、Amazon Aurora MySQL DB クラスタのアップグレードを参照してください。

本記事は、Upgrade to Amazon Aurora MySQL version 3 (with MySQL 8.0 compatibility) を翻訳したものです。翻訳はソリューションアーキテクトの鈴木大樹が担当しました。

著者について

Shagun Arora は、Amazon Web Services のデータベース専門ソリューションアーキテクトです。AWS クラウド上でスケーラブルで高可用性かつセキュアなソリューションの設計を顧客とともに行っています。

Dilip Simhaは、Amazon Aurora MySQL チームのエンジニアリングマネージャーです。エンタープライズソフトウェア分野に 20 年の経験があり、この 5 年間は Amazon で働いています。

Aditi Sharma は AWS のテクニカルアカウントマネージャーで、RDS データベースチームのクラウドサポートエンジニアとしてキャリアをスタートし様々なデータベースエンジンを取り扱いました。テクニカルアカウントマネージャーの役割に就く前に、AWS でいくつかの役割を経験しています。AWS への入社前は銀行業界でソフトウェア開発エンジニアとして働いていました。管理情報システムの修士号とコンピューターサイエンスエンジニアリングの学士号を持っており、認定スクラムマスター、製品オーナー、AWS Database specialty、AWS Solutions Architect の資格も取得しています。

Isael Pimentel は、複雑なインフラストラクチャの開発と管理に 15 年以上の経験を持つ AWS のシニアテクニカルアカウントマネージャーで、AWS Solutions Architect、AWS Network Specialty、 AWS Security Specialty、MSCA、CCNA など、複数の認定資格を持っています。

Amazon Web Services ブログ