テーブルの .frm ファイルと InnoDB データディクショナリの間で MySQL 5.7 インスタンスのスキーマが一致しないと、MySQL 8.0 へのアップグレードが失敗する可能性があります。 このような不一致は、.frm ファイルの破損が原因である可能性があります。 この問題に対処するには、アップグレードを再試行する前に、影響を受けるテーブルをダンプしてリストアします。

新しい mysqld サーバーが起動しないなどの問題が発生した場合は、以前のインストールの古い my.cnf ファイルがないことを確認します。 これは --print-defaults オプション (たとえば、mysqld --print-defaults) で確認できます。 このコマンドがプログラム名以外の何かを表示した場合、サーバーあるいはクライアントオペレーションに影響を及ぼすアクティブな my.cnf ファイルがあることになります。

アップグレード後に、コンパイル済みのクライアントプログラムに Commands out of sync または予測外のコアダンプなどの問題が発生した場合は、プログラムのコンパイル時に、古いヘッダーファイルまたはライブラリファイルを使用した可能性があります。 この場合、mysql.h ファイルおよび libmysqlclient.a ライブラリの日付をチェックして、それらが新しい MySQL 配布のものであることを確認します。 そうでない場合には、プログラムを新しいヘッダーおよびライブラリで再度コンパイルします。 ライブラリのメジャーバージョン番号が (たとえば、libmysqlclient.so.20 から libmysqlclient.so.21 に) 変更された場合、共有クライアントライブラリに対してコンパイルされたプログラムに再コンパイルが必要になることもあります。

ユーザー定義関数 (UDF) を所定の名前で作成したあとで、MySQL を同じ名前の組み込み関数を実装した新しいバージョンにアップグレードした場合、その UDF はアクセスできなくなります。 これを修正するには、DROP FUNCTION を使用して UDF を削除してから、CREATE FUNCTION を使用して競合しない別の名前で UDF を再作成します。 新しいバージョンの MySQL が、既存のストアドファンクションと同名の組み込み関数を実装している場合にも、同じとこが言えます。 各種の関数への参照をサーバーが解釈する方法を記述したルールについては、セクション9.2.5「関数名の構文解析と解決」を参照してください。

セクション2.11.5「アップグレード用のインストールの準備」 で概説されている問題のいずれかが原因で MySQL 8.0 へのアップグレードが失敗した場合、サーバーはすべての変更をデータディレクトリに戻します。 この場合は、すべての redo ログファイルを削除し、既存のデータディレクトリで MySQL 5.7 サーバーを再起動してエラーに対処します。 redo ログファイル (ib_logfile*) は、デフォルトでは MySQL データディレクトリにあります。 エラーが修正されたら、アップグレードを再試行する前に、(innodb_fast_shutdown=0 を設定して) 低速な停止を実行します。