Amazon Aurora MySQL バージョン 2 (MySQL 5.7 互換) からバージョン 3 (MySQL 8.0 互換) へのアップグレードのチェックリスト、パート 1

本記事は、Amazon Aurora MySQL version 2 (with MySQL 5.7 compatibility) to version 3 (with MySQL 8.0 compatibility) upgrade checklist, Part 1 を翻訳したものです。

Amazon Aurora MySQL 互換エディション バージョン 2 (MySQL 5.7 互換)は 2024 年 10 月 31 日に標準サポートの終了が予定されています。Amazon Aurora MySQL バージョン 2 の標準サポートの終了タイムラインについては公開ドキュメント にて説明されています。お客様のデータベースを 2024 年 10 月 31 日より前にできるだけ早く Amazon Aurora MySQL 3 のデフォルトマイナーバージョン以上へアップグレードすることをお勧めします。Amazon Aurora MySQL バージョン 3 (MySQL 8.0 互換)では コミュニティエディションからの改善、Amazon Aurora Serverless V2、 Amazon Aurora ゼロ ETL, Amazon Aurora I/O 最適化、 拡張バイナリログ や AWS Graviton3 サポート など多くの利点が提供されます。

アップグレード操作にはアップグレード実施中にアプリケーションのダウンタイムが必要となります。Amazon Aurora MySQL はクラスター全体のエンジンバージョンをアップグレードします。そのため、アップグレードはライターおよびリーダー DB インスタンスで同時に実施されます。アップグレード時間はテーブルやインデックスの数を含むスキーマのプロパティや、データベースメタデータのサイズ、クラスタの負荷状況など多くの要因に依存します。データベースクローンでアップグレードをテストすることで、アップグレードにかかる時間を決定することができます。テスト環境を作成すると追加のコストが発生することに注意してください。

アップグレードはインプレースアップグレード、スナップショットリストア、または Amazon RDS ブルー/グリーンデプロイメントを使用して実行できます。RDS ブルー/グリーンデプロイメントは、アップグレード時にアプリケーションのダウンタイムを最小限に抑えるための推奨方法です。メジャーバージョン間のアップグレードではアップグレードの前後で広範囲かつ慎重な計画およびテストが必要になります。この記事では、アップグレードやアップグレード事前チェックが失敗する最も一般的な原因について説明します。これらの問題はアップグレードを実施する前に対応する必要があります。

アップグレード事前チェック

Amazon Aurora MySQL はメジャーバージョンアップグレードを多段階のプロセスとして実施し、アップグレード事前チェックはプロセスの中の最初のステップです。MySQL 8.0 は多くの改善をもたらしますが、Amazon Aurora MySQL バージョン 2 からバージョン 3 へのアップグレード中に潜在的な問題を発生させる可能性のある、非互換性がいくつかあることに注意が必要です。アップグレードを開始した時、Amazon Aurora MySQL はこれらの非互換性を検知するため自動的に事前チェックを実行します。インプレースアップグレードでは、事前チェックは DB インスタンスがアップグレードのためにシャットダウンされる前に実行されます。そのため、事前チェックは実行時にダウンタイムを発生させません。事前チェックが非互換性を検知した場合、Aurora は DB インスタンスがシャットダウンする前に自動的にアップグレードをキャンセルします。スナップショットリストアや Amazon RDS ブルー/グリーンデプロイを使用する方法では、Aurora MySQL バージョン 3 へのアップグレードプロセスが失敗すると問題はライターインスタンス作成中やアップグレード中に検知されます。Aurora はオリジナルの 5.7 互換のライターインスタンスを維持します。そのため、Amazon Aurora MySQL がアップグレード実施前に実行した事前チェックによるログを検査できます。Aurora はそれぞれの非互換性について詳細な情報をログファイル upgrade-prechecks.log に記録します。このファイルを download-db-log-file-portion CLI コマンドでダウンロードできます。

本番環境のデータベースをアップグレードする前に、クラスターが非互換性問題を持っていないか確認するために、本番環境のデータベースのクローンを作成しクローンクラスターのインプレースアップグレードを実施することがベストプラクティスです。upgrade-prechecks.log ログの detectedProblems フィールドにレベル値がErrorのエントリが含まれる場合、それらの問題を訂正しなければアップグレードを成功できないことを意味します。エラーを要約し関連するオブジェクトと詳細フィールドを表示するため、upgrade-prechecks.log ファイル内容に対して grep -A 2 '"level": "Error"' コマンドを実施できます。そうすると、それぞれのエラー行とその後の２つの行が表示されます。これらには関連するデータベースオブエジェクトの名前と問題の訂正方法のガイダンスが含まれます。以下がその例です。:

grep -A 2 '"level": "Error"' upgrade-prechecks.log

"level": "Error",
"dbObject": "test.testtable1",
"description": "Table test.testtable1 contains one or more capital letters in name while lower_case_table_names = 1"

"level": "Error",
"dbObject": "test.testtable2",
"description": "present in INFORMATION_SCHEMA's INNODB_SYS_TABLES table but missing from TABLES table"

upgrade-prechecks.log ファイルの最後には、軽微または重大な問題のタイプごとにチェックが該当した数が要約されます。ゼロではない errorCount はアップグレードが失敗するであろうことを示します。warningCount は直接的にはアップグレードプロセスには影響しませんが、アップグレード後に発生する可能性のある将来の問題を回避するために、可能な限り修正することをお勧めします。

"errorCount": 2,
"warningCount": 58,
"noticeCount": 0,
"Summary": "2 errors were found. Please correct these issues before upgrading to avoid compatibility issues."

次のセクションでは、アップグレード事前チェックが失敗する最も一般的な原因を紹介します。

クラスターに不整合なデータディクショナリやユーザースキーマ内の中間テーブルがある

データディクショナリはテーブルやインデックスなどのオブジェクトを追跡するメタデータの集合です。MySQL 8 および Amazon Aurora MySQL version 3 はアトミックデータ定義言語(DDL)ステートメントをサポートしますが、MySQL 5.7 および Amazon Aurora MySQL バージョン 2 はサポートしません。それゆえ MySQL 5.7 および Amazon Aurora MySQL バージョン 2 では、DDL が突然中断されると、データディクショナリが不整合なテーブルが発生する可能性があります。この問題は MySQL の設計によるものであり、Amazon Aurora MySQL や Amazon Relational Database (Amazon RDS) for MySQL によって引き起こされるものではありません。不整合なデータディクショナリの問題があるテーブルに対して、upgrade-prechecks.log に次のエラーが記録されます。:

{
"id": "schemaInconsistencyCheck",
"title": "Schema inconsistencies resulting from file removal or corruption",
"status": "OK",
"description": "Error: Following tables show signs that either table datadir directory or frm file was removed/corrupted. Please check server logs, examine datadir to detect the issue and fix it before upgrade",
"detectedProblems": [
{
"level": "Error",
"dbObject": "test.inconsistent_dd_table",
"description": "present in INFORMATION_SCHEMA's INNODB_SYS_TABLES table but missing from TABLES table"
}

{
"id": "getDanglingFulltextIndex",
"title": "Tables with dangling FULLTEXT index reference",
"status": "OK",
"description": "Error: The following tables contain dangling FULLTEXT index which is not supported. It is recommended to rebuild the table before upgrade.",
"detectedProblems": [
{
"level": "Error",
"dbObject": "sandbox.dangling_fulltext_index_table",
"description": "Table sandbox.dangling_fulltext_index_table contains dangling FULLTEXT index. Kindly recreate the table before upgrade."
}

{
"id": "routinesSyntaxCheck",
"title": "MySQL 8.0 syntax check for routine-like objects",
"status": "OK",
"description": "The following objects did not pass a syntax check with the latest MySQL 8.0 grammar. A common reason is that they reference names that conflict with new reserved keywords. You must update these routine definitions and `quote` any such references before upgrading.",
"documentationLink": "https://dev.mysql.com/doc/refman/en/keywords.html",
"detectedProblems": [
{
"level": "Error",
"dbObject": "test.EXCEPT",
"description": "at line 12,8: unexpected token '.'"
}

2023-09-19T03:11:27.361837Z 2 [ERROR] [MY-013140] [Server] Comment for table 'test.problematic_tables' contains an invalid utf8mb3 character string: '\x8E\xE8\x94'.