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"
}

アップグレード中にこの問題を見つけた時、次のオプションが可能であれば、まずこれらを試すことをお勧めします。:

論理ダンプを実行して新しいクラスターに復元し、新しいクラスターを Aurora MySQL v3 にアップグレードします。この戦略は、問題のあるテーブルは新しいクラスターに移行されないため、問題のあるテーブルがもう必要ないことを前提としています。mysqldump か並列スレッド用に mydumper や myloader を使用できます。
バイナリログレプリカクラスターがある場合は、そこに同じ問題が存在しないことを再確認した上で、レプリカラグがないタイミングでそれらをスタンドアロンクラスターに昇格させます。
問題の原因となった DDL/DCL が実行された時刻がわかっている場合は、元の DCL または DDL が開始された時刻の前までポイントインタイムリカバリ (PiTR) を実行します。データ損失を最小限にするために、復元されたクラスターに差分を移行します。

これらのオプションがどれも有効ではない場合は、AWS サポートまでお問い合わせください。ただしデータディクショナリ不整合の修正はベストエフォートベースで行われることに注意してください。ディクショナリが回復不可能な状態である場合があります。

クラスターに孤立したFULLTEXT インデックスを含むテーブルがある

FULLTEXT インデックスの作成と削除は一部のメタデータを残す可能性があり、これによりアップグレードの事前チェックが失敗しアップグレードがロールバックされます。この孤立したインデックスは、ダングリング FULLTEXT インデックスと呼ばれます。ダングリング FULLTEXT インデックスを含み問題のあるテーブルに関する情報は upgrade-prechecks.log ファイルに出力されます。:

{
"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."
}

ダングリング FULLTEXT 問題を解決するには、Aurora MySQL v2 クラスター上のテーブルに対して OPTIMIZE TABLE コマンドを実行します。たとえば、OPTIMIZE TABLE Sandbox.dangling_fulltext_index_table;となります。

クラスターに予約キーワードを持つオブジェクトがある

MySQL 8.0 では以前は予約されていなかった予約キーワードが導入されました。アップグレードプリチェッカーは、データベースオブジェクトの名前とその定義および本文での、予約キーワードの使用を評価します。ストアドプロシージャ、関数、イベント、トリガーなどのデータベースオブジェクトで使用されている予約キーワードが検出されると、アップグレードは失敗し upgrade-prechecks.log ファイルにエラーが出力されます。:

{
"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 '.'"
}

この問題を解決するためにはアップグレード前に、これらのオブジェクトの定義を更新し全てのそのような参照を’クォート’する必要があります。もしくは別名に名前を変更することもできますが、これはアプリケーションの変更も必要とする可能性があります。

クラスターに無効な文字を含むカラム定義を持つテーブルがある

Amazon Aurora MySQL DB クラスターをアップグレードしようした時、テーブルのカラムコメント定義に無効な文字が含まれているためにアップグレードが失敗する可能性があります。エラーログに次のエラーが表示される場合があります。:

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'.

すべての問題のあるテーブルを特定するためエンジンエラーログを調べ、これらのテーブルに対して SHOW CREATE TABLE <table_name> コマンドを実行し、詳細を確認するため SHOW WARNINGS を使用して警告を確認することをお勧めします。アップグレードを再試行する前に、カラムコメント定義を更新する必要があります。

アップグレードの失敗の原因となるその他の一般的な問題の情報については、MySQL 8.0 の変更点を参照してください。

結論

この記事では、アップグレードの事前チェックプロセス、アップグレードおよびアップグレードの事前チェック失敗の原因となる一般的な問題、およびそれらの問題の解決方法について説明しました。パート 2 では、Amazon Aurora MySQL 2 から Amazon Aurora MySQL 3 へのアップグレードが長引いたり失敗したりする一般的な原因について説明します。

著者について

Huy Nguyen は AWS サポートのシニアエンジニアで、Amazon RDS、Amazon Aurora を専門としています。彼は AWS クラウドにおいてスケーラブルで、可用性が高くかつ安全なソリューションを構築できるよう、顧客にガイダンスと技術支援を提供しています。

Leevon Abuan はAWS サポートのデータベースエンジニアです。彼は Amazon RDS と Amazon Aurora に重点を置き、クラウドにてデータベースを実行する際の複雑な技術的問題の解決のため、顧客を支援してきました。

本記事の翻訳はクラウドサポートエンジニアの吉村悠が担当しました。

Amazon Web Services ブログ