Azure上でMySQL5.7から8.0へのアップグレード検証で異常終了する

こんにちは。Kazuhiro Hozu,

Microsoft Q&Aをご利用いただき、ありがとうございます。

翻訳にはGoogle翻訳を使用しました。文法的な誤りがありましたらご容赦ください。

約1時間経過後に一貫して InternalServerError となり、検証が失敗するという事象は、ユーザーが設定可能なタイムアウトが原因ではありません。むしろ、これは通常、Azure側のアップグレード前検証プロセスが、内部的な制限に達しているか、あるいは実行中に予期せぬエラーに遭遇していることを示しています。

MySQL 5.7から8.0へのアップグレードにおいて、checkServerVersionUpgradeAvailability 操作は、スキーマの互換性、非推奨機能、エンジンの制約など、多岐にわたるチェックを実行します。このように決まった時間で失敗する場合、その原因の多くは、メタデータ処理がバックエンドの許容範囲を超えてしまうような大規模かつ複雑なスキーマにあるか、あるいはサービス側で具体的なエラー内容を明確に特定できず、代わりに一般的なエラーを返してしまうような互換性の問題にあると考えられます。

環境の検証をより確実に行うには、MySQL Shellを使用して手動でMySQLアップグレードチェッカーを実行することをお勧めします。

mysqlsh --uri <user>@<host>:3306 -- util checkForServerUpgrade

このツールを実行すると、非推奨の構文、削除されたシステム変数、互換性のないインデックス、あるいは認証プラグインなど、8.0へのアップグレードを阻害する可能性のある問題に関する詳細なレポートが出力されます。

また、リソースへの負荷が検証プロセスに影響を及ぼす可能性があるため、サーバーへの負荷が低い時間帯を選んで検証を実行し、サーバーが過負荷状態にないことを確認することも有効です。さらに、使用されていないスキーマの整理、可能な範囲でのオブジェクト数の削減、そしてすべてのテーブルがInnoDBのようなサポート対象のストレージエンジンを使用していることの確認なども、検証が正常に完了する可能性を高めるのに役立ちます。

要約しますと、今回の事象は、設定を変更して延長できるような「タイムアウト」によるものではありません。決まった時間（約1時間）で失敗するという挙動は、通常、バックエンドの処理制限や潜在的な互換性の問題を指し示しています。そのため、MySQL Shellを用いた検証を行うことが、アップグレードを再試行する前に、阻害要因を特定し解決するための最も効果的な手段となります。