Aurora MySQL のメジャーバージョンアップグレードの事前チェック
MySQL 5.7 から MySQL 8.0 のように、MySQL をあるメジャーバージョンから別のメジャーバージョンにアップグレードするには、アーキテクチャの大幅な変更が伴うため、慎重な計画と準備が必要です。データベースエンジンソフトウェアの更新や、場合によってはシステムテーブルの更新に主に焦点を当てるマイナーバージョンアップグレードとは異なり、MySQL のメジャーアップグレードでは、データベースのメタデータの保存と管理方法に根本的な変更が加えられることがよくあります。
このような非互換性の特定を支援するために、Aurora MySQL バージョン 2 からバージョン 3 にアップグレードする際、Aurora はアップグレード互換性チェック (事前チェック) を自動的に実行して、データベースクラスター内のオブジェクトを調べ、アップグレードの進行をブロックする可能性のある既知の非互換性を特定します。Aurora MySQL 事前チェックの詳細については、「Aurora MySQL の事前チェックの説明リファレンス」を参照してください。Aurora 事前チェックは、コミュニティ MySQL アップグレードチェッカーユーティリティ
これらの事前確認は必須です。スキップすることはできません。事前チェックには次の利点があります。
-
これにより、ダウンタイムの延長につながるアップグレード障害が発生する可能性を減らすことができます。
-
非互換性がある場合、Amazon Aurora はアップグレードの続行を阻止し、詳細を示すログを出力します。ログを使用して、非互換性を解決することにより、データベースをバージョン 3 にアップグレードする準備を行うことができます。非互換性の解決の詳細については、MySQL ドキュメントの「Preparing your installation for upgrade
」と「Upgrading to MySQL 8.0?」を参照してください。MySQL Server ブログの「知っておくべきこと 」を参照してください。 MySQL 8.0 へのアップグレードの詳細については、MySQL ドキュメントの「MySQL のアップグレード
」を参照してください。
事前チェックは、DB クラスターがメジャーバージョンアップグレードのためにオフラインになる前に実行されます。事前チェックで非互換性が見つかった場合、DB インスタンスが停止する前に、Aurora により自動的にアップグレードがキャンセルされます。Aurora では、非互換性のためのイベントも生成されます。Amazon Aurora イベントの詳細については、「Amazon RDS イベント通知の操作」を参照してください。
事前チェックが完了すると、Aurora はそれぞれの非互換性に関する詳細情報を upgrade-prechecks.log
ファイルに記録します。ほとんどの場合、ログエントリには非互換性を修正するための MySQL のドキュメントへのリンクが含まれています。ログの表示の詳細については、「データベースログファイルの表示とリスト化」を参照してください。
注記
事前チェックの性質上、データベース内のオブジェクトが分析されます。この分析によりリソースが消費され、アップグレードが完了するまでの時間が長くなります。事前チェックのパフォーマンスに関する考慮事項の詳細については、「Aurora MySQL の事前チェックプロセス」を参照してください。
目次
Aurora MySQL の事前チェックプロセス
前述のように、Aurora MySQL のアップグレードプロセスでは、メジャーバージョンのアップグレードを続行する前に、データベースの互換性チェック (事前チェック) を実行します。
インプレースアップグレードの場合、事前チェックはライター DB インスタンスがオンラインの間に実行されます。事前チェックが成功すると、アップグレードが続行されます。エラーが見つかった場合、upgrade-prechecks.log
ファイルに記録され、アップグレードはキャンセルされます。アップグレードを再試行する前に、upgrade-prechecks.log
ファイルで返されたエラーを解決します。
スナップショット復元アップグレードの場合、復元プロセス中に事前チェックが実行されます。成功すると、データベースは新しい Aurora MySQL バージョンにアップグレードされます。エラーが見つかった場合、upgrade-prechecks.log
ファイルに記録され、アップグレードはキャンセルされます。アップグレードを再試行する前に、upgrade-prechecks.log
ファイルで返されたエラーを解決します。
詳細については、Aurora MySQL メジャーバージョンアップグレードが失敗する理由を確認するおよびAurora MySQL の事前チェックの説明リファレンスを参照してください。
事前チェックのステータスをモニタリングするには、DB クラスターで次のイベントを表示できます。
事前チェックのステータス | イベントメッセージ | アクション |
---|---|---|
Started |
アップグレードの準備中: オンラインアップグレードの事前チェックを開始しました。 |
なし |
[失敗] |
データベースクラスターはアップグレードできない状態です: アップグレードの事前チェックに失敗しました。詳細については、upgrade-prechecks.log ファイルを参照してください。 アップグレード失敗の原因のトラブルシューティングの詳細については、以下を参照してください。 |
エラーを修正します。 アップグレードを再試行します。 |
成功 |
アップグレードの準備中: オンラインアップグレードの事前チェックを完了しました。 |
事前チェックは成功し、エラーは返されませんでした。
|
イベントの表示の詳細については、「Amazon RDS イベントの表示」を参照してください。
Aurora MySQL の事前チェックのログ形式
アップグレードの互換性チェック (事前チェック) が完了したら、upgrade-prechecks.log
ファイルを確認できます。ログファイルには、各事前チェックの結果、影響を受けるオブジェクト、および修復情報が含まれます。
エラーがあると、アップグレードできません。アップグレードを再試行する前に解決する必要があります。
警告や通知はそれほど重要ではありませんが、アプリケーションのワークロードとの互換性の問題がないことを確認するために、注意深く確認することをお勧めします。特定された問題はすぐに対処してください。
ログファイルの形式は次のとおりです。
-
targetVersion
– Aurora MySQL アップグレードの MySQL 互換バージョンです。 -
auroraServerVersion
– 事前チェックが実行された Aurora MySQL バージョンです。 -
auroraTargetVersion
– アップグレード先の Aurora MySQL バージョンです。 -
checksPerformed
– 実行された事前チェックのリストが含まれています。 -
id
– 実行中の事前チェックの名前です。 -
title
– 実行中の事前チェックの説明です。 -
status
– これは、事前チェックが成功したか失敗したかを示すものではありませんが、事前チェッククエリのステータスを表示します。-
OK
– 事前チェッククエリが実行され、正常に完了しました。 -
ERROR
– 事前チェッククエリの実行に失敗しました。これは、リソースの制約、予期しないインスタンスの再起動、互換性の事前チェッククエリが中断されたなどの問題が原因で発生する可能性があります。詳細については、この例を参照してください。
-
-
description
– 非互換性の一般的な説明と、問題を修正する方法です。 -
documentationLink
– 該当する場合、関連する Aurora MySQL または MySQL ドキュメントへのリンクをここに示します。詳細については、「Aurora MySQL の事前チェックの説明リファレンス」を参照してください。 -
detectedProblems
– 事前チェックでエラー、警告、または通知が返された場合、該当する場合には非互換性の詳細と非互換オブジェクトが表示されます。-
level
– 事前チェックで検出された非互換性のレベルです。有効なレベルは次のとおりです。-
Error
– 非互換性を解決するまで、アップグレードを続行することはできません。 -
Warning
– アップグレードは続行できますが、非推奨のオブジェクト、構文、または設定が検出されました。警告を注意深く確認し、今後のリリースでの問題を避けるため、すぐに解決してください。 -
Notice
– アップグレードは続行できますが、非推奨のオブジェクト、構文、または設定が検出されました。通知を注意深く確認し、今後のリリースでの問題を避けるため、すぐに解決してください。
-
-
dbObject
– 非互換性が検出されたデータベースオブジェクトの名前です。 -
description
– 非互換性の詳細な説明と、問題の修正方法です。
-
-
errorCount
– 検出された非互換性エラーの数です。これらにより、アップグレードがブロックされています。 -
warningCount
– 検出された非互換性警告の数です。これらはアップグレードをブロックするものではありませんが、今後のリリースでの問題を避けるため、すぐに対処してください。 -
noticeCount
– 検出された非互換性通知の数です。これらはアップグレードをブロックするものではありませんが、今後のリリースでの問題を避けるため、すぐに対処してください。 -
Summary
– 事前チェックの互換性エラー、警告、通知数の概要です。
Aurora MySQL の事前チェックログ出力例
次の例は、表示される可能性のある事前チェックログ出力を示しています。実行される事前チェックの詳細については、「Aurora MySQL の事前チェックの説明リファレンス」を参照してください。
- 事前チェックのステータスは OK で、非互換性は検出されませんでした。
-
事前チェッククエリが正常に完了しました。非互換性は検出されませんでした。
{ "id": "auroraUpgradeCheckIndexLengthLimitOnTinytext", "title": "Check for the tables with indexes defined with prefix length greater than 255 bytes on tiny text columns", "status": "OK", "detectedProblems": [] },
- 事前チェックのステータスは OK で、エラーが検出されました。
-
事前チェッククエリが正常に完了しました。1 つのエラーが検出されました。
{ "id": "auroraUpgradeCheckForPrefixIndexOnGeometryColumns", "title": "Check for geometry columns on prefix indexes", "status": "OK", "description": "Consider dropping the prefix indexes of geometry columns and restart the upgrade.", "detectedProblems": [ { "level": "Error", "dbObject": "test25.sbtest1", "description": "Table `test25`.`sbtest1` has an index `idx_t1` on geometry column/s. Mysql 8.0 does not support this type of index on a geometry column https://dev.mysql.com/worklog/task/?id=11808. To upgrade to MySQL 8.0, Run 'DROP INDEX `idx_t1` ON `test25`.`sbtest1`;" }, }
- 事前チェックのステータスは OK で、警告が検出されました。
-
警告は、事前チェックが成功または失敗したときに返されます。
ここでは、事前チェッククエリが正常に完了しました。2 つの警告が検出されました。
{ "id": "zeroDatesCheck", "title": "Zero Date, Datetime, and Timestamp values", "status": "OK", "description": "Warning: By default zero date/datetime/timestamp values are no longer allowed in MySQL, as of 5.7.8 NO_ZERO_IN_DATE and NO_ZERO_DATE are included in SQL_MODE by default. These modes should be used with strict mode as they will be merged with strict mode in a future release. If you do not include these modes in your SQL_MODE setting, you are able to insert date/datetime/timestamp values that contain zeros. It is strongly advised to replace zero values with valid ones, as they may not work correctly in the future.", "documentationLink": "https://lefred.be/content/mysql-8-0-and-wrong-dates/", "detectedProblems": [ { "level": "Warning", "dbObject": "global.sql_mode", "description": "does not contain either NO_ZERO_DATE or NO_ZERO_IN_DATE which allows insertion of zero dates" }, { "level": "Warning", "dbObject": "session.sql_mode", "description": " of 10 session(s) does not contain either NO_ZERO_DATE or NO_ZERO_IN_DATE which allows insertion of zero dates" } ] }
- 事前チェックのステータスは ERROR で、非互換性は報告されていません。
-
事前チェッククエリがエラーで失敗したため、非互換性を検証できませんでした。
{ "id": "auroraUpgradeCheckForDatafilePathInconsistency", "title": "Check for inconsistency related to ibd file path.", "status": "ERROR", "description": "Can't connect to MySQL server on 'localhost:3306' (111) at 13/08/2024 12:22:20 UTC. This failure can occur due to low memory available on the instance for executing upgrade prechecks. Please check 'FreeableMemory' Cloudwatch metric to verify the available memory on the instance while executing prechecks. If instance ran out of memory, we recommend to retry the upgrade on a higher instance class." }
この障害は、予期しないインスタンスの再起動や、データベースで互換性の事前チェッククエリが実行中に中断されたために発生する可能性があります。例えば、小規模な DB インスタンスクラスでは、インスタンスで使用可能なメモリが少なくなると、この状態になることがあります。
FreeableMemory
Amazon CloudWatch メトリクスを使用して、事前チェックの実行中にインスタンスで使用可能なメモリを確認できます。インスタンスがメモリ不足になった場合は、より大きな DB インスタンスクラスでアップグレードを再試行することをお勧めします。場合によっては、ブルー/グリーンデプロイを使用できます。これにより、システムリソースを消費する本番稼働ワークロードから独立した「グリーン」DB クラスターで事前チェックとアップグレードを実行できます。詳細については、「Aurora MySQL データベースのメモリ使用量に関する問題のトラブルシューティング」を参照してください。
- 事前チェックの結果、1 つのエラーと 3 つの警告が検出されました。
-
互換性の事前チェックには、ソースおよびターゲットの Aurora MySQL バージョンに関する情報が含まれており、事前チェック出力の最後にはエラー、警告、通知数の概要があります。
例えば、次の出力は、Aurora MySQL 2.11.6 から Aurora MySQL 3.07.1 にアップグレードしようとしたことを示しています。アップグレードで 1 つのエラーと 3 つの警告が返され、通知はありませんでした。エラーが返されるとアップグレードを続行できないため、routineSyntaxCheck の互換性の問題を解決し、アップグレードを再試行する必要があります。
{ "serverAddress": "/tmp%2Fmysql.sock", "serverVersion": "5.7.12 - MySQL Community Server (GPL)", "targetVersion": "8.0.36", "auroraServerVersion": "2.11.6", "auroraTargetVersion": "3.07.1", "outfilePath": "/rdsdbdata/tmp/PreChecker.log", "checksPerformed": [{ ... output for each individual precheck ... . . { "id": "oldTemporalCheck", "title": "Usage of old temporal type", "status": "OK", "detectedProblems": [] }, { "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.select_res_word", "description": "at line 2,18: unexpected token 'except'" }] }, . . . { "id": "zeroDatesCheck", "title": "Zero Date, Datetime, and Timestamp values", "status": "OK", "description": "Warning: By default zero date/datetime/timestamp values are no longer allowed in MySQL, as of 5.7.8 NO_ZERO_IN_DATE and NO_ZERO_DATE are included in SQL_MODE by default. These modes should be used with strict mode as they will be merged with strict mode in a future release. If you do not include these modes in your SQL_MODE setting, you are able to insert date/datetime/timestamp values that contain zeros. It is strongly advised to replace zero values with valid ones, as they may not work correctly in the future.", "documentationLink": "https://lefred.be/content/mysql-8-0-and-wrong-dates/", "detectedProblems": [{ "level": "Warning", "dbObject": "global.sql_mode", "description": "does not contain either NO_ZERO_DATE or NO_ZERO_IN_DATE which allows insertion of zero dates" }, { "level": "Warning", "dbObject": "session.sql_mode", "description": " of 8 session(s) does not contain either NO_ZERO_DATE or NO_ZERO_IN_DATE which allows insertion of zero dates" } ] }, . . . }], "errorCount": 1, "warningCount": 3, "noticeCount": 0, "Summary": "1 errors were found. Please correct these issues before upgrading to avoid compatibility issues." }
Aurora MySQL の事前チェックパフォーマンス
互換性の事前チェックは、アップグレードのために DB インスタンスがオフラインになる前に実行されるため、通常の状況では、実行中に DB インスタンスのダウンタイムが発生することはありません。ただし、ライター DB インスタンスで実行されているアプリケーションのワークロードに影響を与える可能性があります。事前チェックは、information_schema
-
事前チェックの期間は、テーブル、列、ルーチン、制約などのデータベースオブジェクトの数によって異なります。オブジェクトの数が多い DB クラスターの実行には時間がかかる場合があります。
例えば、removedFunctionsCheck は、保存されているオブジェクト
の数に基づいて、より長い時間がかかり、より多くのリソースを使用する場合があります。 -
インプレースアップグレードでは、より大きな DB インスタンスクラス (db.r5.24xlarge や db.r6g.16xlarge など) を使用すると、より多くの CPU を使用してアップグレードを迅速に完了できます。アップグレード後にダウンサイズできます。
-
複数のデータベースにわたる
information_schema
に対するクエリは、特にオブジェクトが多く、DB インスタンスが小さい場合に遅くなる可能性があります。このような場合は、アップグレードのためにクローン作成、スナップショット復元、またはブルー/グリーンデプロイを使用することを検討してください。 -
事前チェックのリソース使用量 (CPU、メモリ) は、オブジェクトが増えるほど増加し、DB インスタンスが小さくなるほど実行時間が長くなる可能性があります。このような場合は、アップグレードのためにクローン作成、スナップショット復元、またはブルー/グリーンデプロイの使用をテストすることを検討してください。
リソース不足が原因で事前チェックが失敗した場合、ステータス出力を使用して、事前チェックログで検出できます。
"status": "ERROR",
詳細については、メジャーバージョンの Aurora MySQL インプレースアップグレードの仕組みおよびAurora MySQL クラスターのメジャーバージョンアップグレードの計画を参照してください。
コミュニティ MySQL アップグレードの事前チェックの概要
以下は、MySQL 5.7 から 8.0 までの非互換性の一般的なリストです。
-
MySQL 5.7 互換 DB クラスターでは、MySQL 8.0 でサポートされていない機能を使用しないでください。
詳細については、MySQL ドキュメントの「MySQL 8.0 で削除された機能
」を参照してください。 -
キーワードや予約語に違反してはいけません。MySQL 8.0 では、以前に予約されていなかったキーワードもあります。
詳細については、MySQL ドキュメントの「キーワードと予約語
」を参照してください。 -
Unicode サポートの改善のため、
utf8mb3
文字セットを使用するオブジェクトを、utf8mb4
文字セットを使用するように変換することを検討してください。utf8mb3
文字セットは廃止されました。また、utf8mb4
の代わりにutf8
を文字セット参照に使用することを検討してください。現在utf8
はutf8mb3
文字セットの別名であるためです。詳細については、MySQL ドキュメントの「utf8mb3 文字セット (3 バイトの UTF-8 Unicode エンコード)
」を参照してください。 -
デフォルト以外の行形式の InnoDB テーブルは使用できません。
-
ZEROFILL
またはdisplay
の長さ型属性は使用できません。 -
ネイティブのパーティショニングをサポートしていないストレージエンジンを使用するパーティショニングされたテーブルがあってはいけません。
-
MySQL 5.7 の
mysql
システムデータベースに、MySQL 8.0 データディクショナリで使用されるテーブルと同じ名前のテーブルがあってはいけません。 -
テーブルで古いデータ型や関数を使用してはいけません。
-
64 文字を超える外部キーの制約名があってはいけません。
-
sql_mode
システム可変設定で、古い SQL モードを定義してはいけません。 -
長さが 255 文字を超える
ENUM
またはSET
列要素をそれぞれ持つテーブルまたはストアドプロシージャが存在してはいけません。 -
共有 InnoDB テーブルスペースに存在するテーブルパーティションが存在してはいけません。
-
表領域データファイルパスに循環参照が存在してはいけません。
-
ASC
句にDESC
またはGROUP BY
修飾子を使用するクエリおよびストアドプログラム定義が存在してはいけません。 -
削除されたシステム変数が存在してはならず、システム変数は MySQL 8.0 の新しいデフォルト値を使用する必要があります。
-
ゼロ (
0
) の日付、日時、タイムスタンプ値は使用できません。 -
ファイルの削除または破損によるスキーマの不一致が存在してはいけません。
-
FTS
文字列を含むテーブル名が存在してはいけません。 -
別のエンジンに属する InnoDB テーブルが存在してはいけません。
-
MySQL 5.7 に無効なテーブル名またはスキーマ名が存在してはいけません。
実行される事前チェックの詳細については、「Aurora MySQL の事前チェックの説明リファレンス」を参照してください。
MySQL 8.0 へのアップグレードの詳細については、MySQL ドキュメントの「MySQL のアップグレード
Aurora MySQL アップグレードの事前チェックの概要
バージョン 2 からバージョン 3 にアップグレードする場合、Aurora MySQL には以下のような独自の固有要件があります。
-
ビュー、ルーチン、トリガー、イベントに、
SQL_CACHE
、SQL_NO_CACHE
、QUERY_CACHE
などの非推奨の SQL 構文があってはいけません。 -
FTS
インデックスのないテーブルにはFTS_DOC_ID
列が存在しない必要があります。 -
InnoDB データディクショナリと実際のテーブル定義の間に列定義の不一致が存在してはいけません。
-
lower_case_table_names
パラメータが1
に設定されている場合は、すべてのデータベース名とテーブル名を小文字にする必要があります。 -
イベントとトリガーの definer は欠落していても、空にすることもできず、トリガーに無効な作成コンテキストでもいけません。
-
データベース内のすべてのトリガー名は一意である必要があります。
-
DDL リカバリと高速 DDL は、Aurora MySQL バージョン 3 ではサポートされていません。これらの機能に関連するデータベースにアーティファクトが存在してはいけません。
-
REDUNDANT
またはCOMPACT
行形式のテーブルには、767 バイトを超えるインデックスを含めることはできません。 -
tiny
テキスト列に定義されているインデックスのプレフィックスの長さは 255 バイトを超えることはできません。utf8mb4
文字セットでは、サポートされるプレフィックスの長さは 63 文字に制限されます。MySQL 5.7 では、
innodb_large_prefix
パラメータを使用して、より大きなプレフィックス長が許可されていました。このパラメータは MySQL 8.0 では廃止されました。 -
mysql.host
テーブルに InnoDB メタデータの不整合が存在してはいけません。 -
システムテーブルに列のデータ型の不一致が存在してはいけません。
-
prepared
状態の XA トランザクションが存在してはいけません。 -
ビューの列名は 64 文字以下にする必要があります。
-
ストアドプロシージャの特殊文字に一貫性を持たせることはできません。
-
テーブルにデータファイルパスの不整合が存在してはいけません。
実行される事前チェックの詳細については、「Aurora MySQL の事前チェックの説明リファレンス」を参照してください。