このページは機械翻訳したものです。

2.11.4 MySQL 8.0 での変更

MySQL 8.0 にアップグレードする前に、このセクションで説明されている変更を確認して、現在の MySQL インストールおよびアプリケーションに適用される変更を特定します。 推奨されるアクションを実行します。

互換性のない変更としてマークされた変更は、以前のバージョンの MySQL との互換性がないため、アップグレード前に注意する必要がある場合があります。 弊社の目的はそれらの変更を避けることですが、各リリースの間の非適合性よりもさらに深刻な問題を修正するために必要である場合もあります。 インストールに適用可能なアップグレードの問題に互換性がない場合は、説明に示されている手順に従ってください。

• データディクショナリの変更

• 優先認証プラグインとしての caching_sha2_password

• 構成の変更

• サーバーの変更

• InnoDB の変更点

• SQL の変更

データディクショナリの変更

MySQL Server 8.0 には、トランザクションテーブルのデータベースオブジェクトに関する情報を含むグローバルデータディクショナリが組み込まれています。 以前の MySQL シリーズでは、ディクショナリデータはメタデータファイルおよび非トランザクションシステムテーブルに格納されていました。 そのため、アップグレード手順では、特定の前提条件を確認して、インストールのアップグレード準備状況を確認する必要があります。 詳細は、セクション2.11.5「アップグレード用のインストールの準備」を参照してください。 データディクショナリ対応サーバーには、一般的な操作上の違いがいくつかあります。セクション14.7「データディクショナリの使用方法の違い」 を参照してください。

優先認証プラグインとしての caching_sha2_password

caching_sha2_password および sha256_password 認証プラグインは、mysql_native_password プラグインよりもセキュアなパスワード暗号化を提供し、caching_sha2_password は sha256_password よりも優れたパフォーマンスを提供します。 caching_sha2_password のこれらの優れたセキュリティおよびパフォーマンス特性のため、MySQL 8.0 が優先認証プラグインであり、mysql_native_password ではなくデフォルトの認証プラグインでもあります。 この変更は、サーバーと libmysqlclient クライアントライブラリの両方に影響します:

• サーバーの場合、default_authentication_plugin システム変数のデフォルト値が mysql_native_password から caching_sha2_password に変更されます。

  この変更は、MySQL 8.0 以上のインストールまたはアップグレード後に作成された新しいアカウントにのみ適用されます。 アップグレードインストールにすでに存在するアカウントの場合、認証プラグインは変更されません。 caching_sha2_password に切り替える既存のユーザーは、ALTER USER ステートメントを使用してこれを実行できます:

  ALTER USER user
    IDENTIFIED WITH caching_sha2_password
    BY 'password';

• libmysqlclient ライブラリは、caching_sha2_password を mysql_native_password ではなくデフォルトの認証プラグインとして扱います。

次の各セクションでは、caching_sha2_password のより有望なロールの影響について説明します:

• caching_sha2_password の互換性の問題および解決策

• caching_sha2_password-Compatible クライアントおよびコネクタ

• caching_sha2_password および root 管理アカウント

• caching_sha2_password とレプリケーション

caching_sha2_password の互換性の問題および解決策

重要

MySQL インストールで 8.0 より前のクライアントを提供する必要があり、MySQL 8.0 以上へのアップグレード後に互換性の問題が発生した場合、これらの問題に対処して 8.0 より前の互換性をリストアする最も簡単な方法は、以前のデフォルトの認証プラグイン (mysql_native_password) に戻すようにサーバーを再構成することです。 たとえば、サーバーオプションファイルで次の行を使用します:

[mysqld]
default_authentication_plugin=mysql_native_password

この設定により、インストールで使用されているクライアントおよびコネクタが caching_sha2_password を認識するようにアップグレードされるまで、8.0 より前のクライアントが 8.0 サーバーに接続できるようになります。 ただし、この設定は、長期または永続的なソリューションとしてではなく、一時的なものとして表示する必要があります。これは、この設定を有効にして作成された新しいアカウントが、caching_sha2_password によって提供される改善された認証セキュリティを予測するためです。

caching_sha2_password を使用すると、mysql_native_password よりもセキュアなパスワードハッシュが提供されます (その結果、クライアント接続認証が改善されます)。 ただし、既存の MySQL インストールに影響する可能性がある互換性の影響もあります:

• caching_sha2_password について知るために更新されていないクライアントおよびコネクタでは、caching_sha2_password で認証されないアカウントを使用する場合でも、caching_sha2_password でデフォルトの認証プラグインとして構成された MySQL 8.0 サーバーへの接続に問題が発生する可能性があります。 この問題は、サーバーがデフォルトの認証プラグインの名前をクライアントに指定しているために発生します。 クライアントまたはコネクタが、認識されないデフォルト認証プラグインを正常に処理しないクライアント/サーバープロトコル実装に基づいている場合、次のいずれかのエラーで失敗する可能性があります:

  Authentication plugin 'caching_sha2_password' is not supported

  Authentication plugin 'caching_sha2_password' cannot be loaded:
  dlopen(/usr/local/mysql/lib/plugin/caching_sha2_password.so, 2):
  image not found

  Warning: mysqli_connect(): The server requested authentication
  method unknown to the client [caching_sha2_password]

  不明なデフォルト認証プラグインに対するサーバーからのリクエストを正常に処理するコネクタの記述の詳細は、認証プラグインコネクタ - 書込みに関する考慮事項 を参照してください。

• caching_sha2_password で認証されるアカウントを使用するクライアントは、セキュアな接続 (TLS/SSL 資格証明、Unix ソケットファイルまたは共有メモリーを使用して TCP を使用して確立) または RSA キーペアを使用したパスワード交換をサポートする暗号化されていない接続を使用する必要があります。 このセキュリティ要件は mysql_native_passsword には適用されないため、caching_sha2_password への切替えには追加の構成が必要になる場合があります (セクション6.4.1.2「SHA-2 プラガブル認証のキャッシュ」 を参照)。 ただし、MySQL 8.0 のクライアント接続では、デフォルトで TLS/SSL を使用することをお薦めします。そのため、そのプリファレンスにすでに準拠しているクライアントでは、追加の構成が必要ない場合があります。

• caching_sha2_password について知るために更新されていないクライアントおよびコネクタは、このプラグインが有効であると認識されないため、caching_sha2_password で認証されるアカウントに接続できません。 (これは、認証プラグインクライアント/サーバーの互換性 で説明されているように、クライアント/サーバー認証プラグインの互換性要件が適用される方法の特定のインスタンスです。) この問題を回避するには、MySQL 8.0 以上から libmysqlclient に対してクライアントを再リンクするか、caching_sha2_password を認識する更新済コネクタを取得します。

• caching_sha2_password は libmysqlclient クライアントライブラリのデフォルトの認証プラグインでもあるため、クライアントプログラムが --default-auth=mysql_native_password オプションで呼び出されないかぎり、MySQL 8.0 クライアントから mysql_native_password (以前のデフォルトの認証プラグイン) を使用するアカウントへの接続には、クライアント/サーバープロトコルで追加のラウンドトリップが必要になります。

8.0 MySQL より前のバージョンの libmysqlclient クライアントライブラリは、MySQL 8.0 サーバー (caching_sha2_password で認証されるアカウントを除く) に接続できます。 つまり、libmysqlclient に基づく 8.0 より前のクライアントも接続できる必要があります。 例:

• mysql や mysqladmin などの標準 MySQL クライアントは libmysqlclient ベースです。

• Perl DBI 用の DBD::mysql ドライバは libmysqlclient ベースです。

• MySQL Connector/Python には、libmysqlclient ベースの C 拡張モジュールがあります。 これを使用するには、接続時に use_pure=False オプションを含めます。

既存の MySQL 8.0 インストールを MySQL 8.0.4 以上にアップグレードする場合、一部の古い libmysqlclient ベースのクライアントは、アップグレードによってインストールされた新しいクライアントライブラリを使用するため、動的にリンクされていれば「「自動」」をアップグレードできます。 たとえば、Perl DBI 用の DBD::mysql ドライバで動的リンクが使用されている場合、MySQL 8.0.4 以上へのアップグレード後に libmysqlclient を使用できます。その結果は次のようになります:

• アップグレードの前に、DBD::mysql を使用する DBI スクリプトは、caching_sha2_password で認証されるアカウントを除き、MySQL 8.0 サーバーに接続できます。

• アップグレード後、同じスクリプトで caching_sha2_password アカウントも使用できるようになります。

ただし、8.0.4 より前の MySQL 8.0 インストールの libmysqlclient インスタンスにはバイナリ互換性があるため、前述の結果になります: どちらの場合も、共有ライブラリのメジャーバージョン番号 21 が使用されます。 MySQL 5.7 以前から libmysqlclient にリンクされているクライアントの場合、バイナリ互換性のない異なるバージョン番号を持つ共有ライブラリにリンクします。 この場合、MySQL 8.0 サーバーおよび caching_sha2_password アカウントとの完全な互換性を確保するために、8.0.4 以上の libmysqlclient に対してクライアントを再コンパイルする必要があります。

MySQL Connector/J 5.1 は 8.0.8 を介して MySQL 8.0 サーバーに接続できますが、caching_sha2_password で認証されるアカウントは例外です。(Connector/J 8.0.9 以上が caching_sha2_password アカウントに接続するために必要です。)

libmysqlclient 以外のクライアント/サーバープロトコルの実装を使用するクライアントは、新しい認証プラグインを認識する新しいバージョンにアップグレードする必要がある場合があります。 たとえば、PHP では、MySQL の接続性は通常、mysqlnd に基づいており、caching_sha2_password については現在認識されていません。 更新されたバージョンの mysqlnd が使用可能になるまで、PHP クライアントが MySQL 8.0 に接続できるようにするには、前述のように、mysql_native_password にデフォルトの認証プラグインとして戻すようにサーバーを再構成します。

クライアントまたはコネクタがデフォルトの認証プラグインを明示的に指定するオプションをサポートしている場合は、それを使用して caching_sha2_password 以外のプラグインに名前を付けます。 例:

• 一部の MySQL クライアントは、--default-auth オプションをサポートしています。 (mysql や mysqladmin などの標準 MySQL クライアントはこのオプションをサポートしていますが、それを使用せずに 8.0 サーバーに正常に接続できます。 ただし、他のクライアントも同様のオプションをサポートする場合があります。 その場合は、試行する価値があります。)

• libmysqlclient C API を使用するプログラムでは、MYSQL_DEFAULT_AUTH オプションを指定して mysql_options() 関数をコールできます。

• クライアント/サーバープロトコルのネイティブ Python 実装を使用する MySQL Connector/Python スクリプトでは、auth_plugin 接続オプションを指定できます。 (または、auth_plugin を必要とせずに MySQL 8.0 サーバーに接続できる Connector/Python C 拡張機能を使用します。)

caching_sha2_password-Compatible クライアントおよびコネクタ

caching_sha2_password について知るために更新されたクライアントまたはコネクタが使用可能な場合は、caching_sha2_password をデフォルトの認証プラグインとして構成された MySQL 8.0 サーバーに接続するときに互換性を確保するための最善の方法です。

次のクライアントおよびコネクタは、caching_sha2_password をサポートするようにアップグレードされています:

• MySQL 8.0 (8.0.4 以上) の libmysqlclient クライアントライブラリ。 mysql や mysqladmin などの標準 MySQL クライアントは libmysqlclient ベースであるため、互換性もあります。

• MySQL 5.7 (5.7.23 以上) の libmysqlclient クライアントライブラリ。 mysql や mysqladmin などの標準 MySQL クライアントは libmysqlclient ベースであるため、互換性もあります。

• MySQL Connector/C++ 1.1.11 以上または 8.0.7 以上。

• MySQL Connector/J 8.0.9 以上。

• MySQL Connector/NET 8.0.10 以上 (クラシック MySQL プロトコルを使用)。

• MySQL Connector/Node.js 8.0.9 以上。

• PHP: X DevAPI PHP 拡張機能 (mysql_xdevapi) は、caching_sha2_password をサポートしています。

  PHP: PDO_MySQL および ext/mysqli 拡張機能は caching_sha2_password をサポートしていません。 また、7.2.4 より前の 7.1.16 および PHP 7.2 より前の PHP バージョンで使用すると、caching_sha2_password が使用されていない場合でも default_authentication_plugin=caching_sha2_password との接続に失敗します。

caching_sha2_password および root 管理アカウント

MySQL 8.0 へのアップグレードの場合、'root'@'localhost'管理アカウントのプラグインを含め、認証プラグインの既存のアカウントは変更されません。

MySQL 8.0 の新規インストールでは、(セクション2.10.1「データディレクトリの初期化」 の手順を使用して) データディレクトリを初期化すると、'root'@'localhost'アカウントが作成され、そのアカウントはデフォルトで caching_sha2_password を使用します。 したがって、データディレクトリの初期化後にサーバーに接続するには、caching_sha2_password をサポートするクライアントまたはコネクタを使用する必要があります。 これを実行できるが、インストール後に root アカウントで mysql_native_password を使用する場合は、MySQL をインストールし、通常どおりにデータディレクトリを初期化します。 次に、root としてサーバーに接続し、次のように ALTER USER を使用してアカウント認証プラグインおよびパスワードを変更します:

ALTER USER 'root'@'localhost'
  IDENTIFIED WITH mysql_native_password
  BY 'password';

使用するクライアントまたはコネクタが caching_sha2_password をまだサポートしていない場合は、アカウントが作成されるとすぐに root アカウントを mysql_native_password に関連付ける変更済データディレクトリ初期化プロシージャを使用できます。 これを行うには、次のいずれかの方法を使用します:

• --initialize または --initialize-insecure とともに --default-authentication-plugin=mysql_native_password オプションを指定します。

• オプションファイルで default_authentication_plugin を mysql_native_password に設定し、--initialize または --initialize-insecure とともに --defaults-file オプションを使用してそのオプションファイルに名前を付けます。 (この場合、後続のサーバー起動にそのオプションファイルを引き続き使用すると、default_authentication_plugin 設定をオプションファイルから削除しないかぎり、caching_sha2_password ではなく mysql_native_password で新しいアカウントが作成されます。)

caching_sha2_password とレプリケーション

すべてのサーバーが MySQL 8.0.4 以上にアップグレードされているレプリケーションシナリオでは、ソースサーバーへのレプリカ接続で、caching_sha2_password で認証されるアカウントを使用できます。 このような接続の場合、caching_sha2_password で認証されるアカウントを使用する他のクライアントと同じ要件が適用されます: セキュアな接続または RSA ベースのパスワード交換を使用します。

ソース/レプリカレプリケーションのために caching_sha2_password アカウントに接続するには:

• 次の CHANGE MASTER TO オプションのいずれかを使用します:

  MASTER_SSL = 1
  GET_MASTER_PUBLIC_KEY = 1
  MASTER_PUBLIC_KEY_PATH='path to RSA public key file'

• または、サーバーの起動時に必要なキーが指定されている場合は、RSA 公開キー関連オプションを使用できます。

グループレプリケーション用の caching_sha2_password アカウントに接続するには:

• OpenSSL を使用して構築された MySQL の場合は、次のいずれかのシステム変数を設定します:

  SET GLOBAL group_replication_recovery_use_ssl = ON;
  SET GLOBAL group_replication_recovery_get_public_key = 1;
  SET GLOBAL group_replication_recovery_public_key_path = 'path to RSA public key file';

• または、サーバーの起動時に必要なキーが指定されている場合は、RSA 公開キー関連オプションを使用できます。

構成の変更

• 互換性のない変更: MySQL ストレージエンジンは独自のパーティショニングハンドラを提供する役割を果たし、MySQL サーバーは一般的なパーティショニングサポートを提供しなくなりました。 MySQL 8.0 でサポートされているネイティブパーティショニングハンドラを提供するストレージエンジンは、InnoDB および NDB のみです。 ほかのストレージエンジンを使用するパーティション化されたテーブルは、InnoDB または NDB に変換するか、サーバーをアップグレードする前にパーティション化を削除するために変更する必要があります。それ以外の場合は、あとで使用できません。

  MyISAM テーブルの InnoDB への変換の詳細は、セクション15.6.1.5「MyISAM から InnoDB へのテーブルの変換」 を参照してください。

  このようなサポートがないストレージエンジンを使用してパーティション化されたテーブルになるテーブル作成ステートメントは、MySQL 8.0 のエラー ( ER_CHECK_NOT_IMPLEMENTED ) で失敗します。 mysqldump を使用して MySQL 5.7 (またはそれ以前) で作成されたダンプファイルから MySQL 8.0 サーバーにデータベースをインポートする場合は、パーティションテーブルを作成するすべてのステートメントで、パーティション化への参照を削除するか、ストレージエンジンを InnoDB として指定するか、デフォルトで InnoDB として設定できるようにして、サポートされていないストレージエンジンも指定しないようにする必要があります。

  注記

  セクション2.11.5「アップグレード用のインストールの準備」 で提供されている手順では、MySQL 8.0 にアップグレードする前に変更する必要があるパーティションテーブルを識別する方法について説明します。

  詳細は、セクション24.6.2「ストレージエンジンに関連するパーティショニング制限」 を参照してください。

• 互換性のない変更: いくつかのサーバーエラーコードが使用されておらず、削除されています (リストについては、MySQL 8.0 で削除された機能 を参照)。 特にテストするアプリケーションは更新する必要があります。

• 重要な変更: デフォルトの文字セットが latin1 から utf8mb4 に変更されました。 次のシステム変数が影響を受けます:

  • character_set_server および character_set_database システム変数のデフォルト値が latin1 から utf8mb4 に変更されました。

  • collation_server および collation_database システム変数のデフォルト値が latin1_swedish_ci から utf8mb4_0900_ai_ci に変更されました。

  その結果、明示的な文字セットと照合順序が指定されていないかぎり、新しいオブジェクトのデフォルトの文字セットと照合順序は以前とは異なります。 これには、データベースおよびその内部のオブジェクト (テーブル、ビュー、ストアドプログラムなど) が含まれます。 以前のデフォルトが使用されていたと仮定すると、これらを保持する方法の 1 つは、my.cnf ファイル内の次の行を使用してサーバーを起動することです:

  [mysqld]
  character_set_server=latin1
  collation_server=latin1_swedish_ci

  レプリケートされた設定では、MySQL 5.7 から 8.0 にアップグレードする場合、アップグレードする前にデフォルトの文字セットを MySQL 5.7 で使用されている文字セットに戻すことをお薦めします。 アップグレードの完了後、デフォルトの文字セットを utf8mb4 に変更できます。

• 互換性のない変更: MySQL 8.0.11 の時点では、サーバーの初期化時に使用された設定とは異なる lower_case_table_names 設定でサーバーを起動することは禁止されています。 様々なデータディクショナリテーブルのフィールドで使用される照合は、サーバーの初期化時に定義された lower_case_table_names 設定に基づいており、異なる設定でサーバーを再起動すると、識別子の順序付けおよび比較方法に矛盾が生じるため、制限が必要です。

サーバーの変更

• MySQL 8.0.11 では、ユーザーアカウントの非権限特性を変更するための GRANT ステートメントの使用、NO_AUTO_CREATE_USER SQL モード、PASSWORD() 関数、old_passwords システム変数など、アカウント管理に関連するいくつかの非推奨機能が削除されました。

  これらの削除された機能を参照するステートメントの MySQL 5.7 から 8.0 へのレプリケーションによって、レプリケーションが失敗する可能性があります。 MySQL 8.0 で削除された機能 で説明されているように、削除された機能のいずれかを使用するアプリケーションを改訂して回避し、可能な場合は代替機能を使用する必要があります。

  MySQL 8.0 での起動の失敗を回避するには、MySQL オプションファイルの sql_mode システム変数設定から NO_AUTO_CREATE_USER のインスタンスを削除します。

  ストアドプログラム定義に NO_AUTO_CREATE_USER SQL モードを含むダンプファイルを MySQL 8.0 サーバーにロードすると、障害が発生します。 MySQL 5.7.24 および MySQL 8.0.13 の時点で、mysqldump はストアドプログラム定義から NO_AUTO_CREATE_USER を削除します。 以前のバージョンの mysqldump で作成されたダンプファイルは、NO_AUTO_CREATE_USER のインスタンスを削除するために手動で変更する必要があります。

• MySQL 8.0.11 では、これらの非推奨の互換性 SQL モードは削除されました: DB2, MAXDB, MSSQL, MYSQL323, MYSQL40, ORACLE, POSTGRESQL, NO_FIELD_OPTIONS, NO_KEY_OPTIONS, NO_TABLE_OPTIONS。 これらを sql_mode システム変数に割り当てたり、mysqldump --compatible オプションの許可された値として使用したりすることはできなくなりました。

  MAXDB を削除すると、CREATE TABLE または ALTER TABLE の TIMESTAMP データ型は DATETIME として扱われなくなります。

  削除された SQL モードを参照するステートメントの MySQL 5.7 から 8.0 へのレプリケーションによって、レプリケーションが失敗する可能性があります。 これには、現在の sql_mode 値に削除されたモードのいずれかが含まれているときに実行されるストアドプログラム (ストアドプロシージャとストアドファンクション、トリガーおよびイベント) の CREATE ステートメントのレプリケーションが含まれます。 削除されたモードのいずれかを使用するアプリケーションは、それらを回避するために改訂する必要があります。

• MySQL 8.0.3 の時点では、空間データ型で SRID 属性を使用して、カラムに格納されている値の空間参照システム (SRS) を明示的に指定できます。 セクション11.4.1「空間データ型」を参照してください。

  明示的な SRID 属性を持つ空間カラムは、SRID 制限付きです: カラムはその ID を持つ値のみを取り、そのカラムの SPATIAL インデックスはオプティマイザによって使用される対象になります。 オプティマイザは、SRID 属性のない空間カラムの SPATIAL インデックスを無視します。 セクション8.3.3「SPATIAL インデックス最適化」を参照してください。 SRID 制限のない空間カラムの SPATIAL インデックスをオプティマイザで考慮する場合は、そのような各カラムを変更する必要があります:

  • カラム内のすべての値が同じ SRID を持つことを確認します。 ジオメトリカラム col_name に含まれる SRID を確認するには、次のクエリーを使用します:

    SELECT DISTINCT ST_SRID(col_name) FROM tbl_name;

    クエリーで複数の行が返された場合、カラムには SRID の混在が含まれます。 その場合は、その内容を変更して、すべての値が同じ SRID を持つようにします。

  • 明示的な SRID 属性を持つようにカラムを再定義します。

  • SPATIAL インデックスを再作成します。

• 正確な操作を実行する関数の ST_接頭辞、または最小境界矩形に基づいて操作を実行する関数の MBR 接頭辞を実装する空間関数ネームスペースの変更により、MySQL 8.0.0 でいくつかの空間関数が削除されました。 生成されたカラム定義で削除された空間関数を使用すると、アップグレードが失敗する可能性があります。 アップグレードする前に、削除された空間関数に対して mysqlcheck --check-upgrade を実行し、見つかったものを ST_または MBR の名前付き置換に置き換えます。 削除された空間関数のリストは、MySQL 8.0 で削除された機能 を参照してください。

• BACKUP_ADMIN 権限は、MySQL 8.0.3 以上へのインプレースアップグレードの実行時に、RELOAD 権限を持つユーザーに自動的に付与されます。

• MySQL 8.0.13 からは、一時テーブルの処理方法における行ベースまたは混合レプリケーションモードとステートメントベースのレプリケーションモードの違いにより、実行時のバイナリロギング形式の切り替えに新しい制限があります。

  • セッションにオープン一時テーブルがある場合、SET @@SESSION.binlog_format は使用できません。

  • いずれかのレプリケーションチャネルにオープン一時テーブルがある場合、SET @@global.binlog_format および SET @@persist.binlog_format は使用できません。 SET @@persist_only.binlog_format は、レプリケーションチャネルにオープン一時テーブルがある場合に許可されます。これは、PERSIST とは異なり、PERSIST_ONLY ではランタイムグローバルシステム変数値が変更されないためです。

  • レプリケーションチャネルアプライヤが実行されている場合、SET @@global.binlog_format および SET @@persist.binlog_format は使用できません。 これは、変更がレプリケーションチャネルで有効になるのは、そのアプライヤが再起動されたときのみであり、そのときにレプリケーションチャネルにオープン一時テーブルがある可能性があるためです。 この動作は、以前よりも制限されています。 SET @@persist_only.binlog_format は、レプリケーションチャネルアプライヤが実行されている場合に許可されます。

InnoDB の変更点

• InnoDB システムテーブルに基づく INFORMATION_SCHEMA ビューは、データディクショナリテーブルの内部システムビューに置き換えられました。 影響を受ける InnoDB INFORMATION_SCHEMA ビューの名前が変更されました:

  表 2.16 名前が変更された InnoDB 情報スキーマビュー

  旧名称	新規名
  INNODB_SYS_COLUMNS	INNODB_COLUMNS
  INNODB_SYS_DATAFILES	INNODB_DATAFILES
  INNODB_SYS_FIELDS	INNODB_FIELDS
  INNODB_SYS_FOREIGN	INNODB_FOREIGN
  INNODB_SYS_FOREIGN_COLS	INNODB_FOREIGN_COLS
  INNODB_SYS_INDEXES	INNODB_INDEXES
  INNODB_SYS_TABLES	INNODB_TABLES
  INNODB_SYS_TABLESPACES	INNODB_TABLESPACES
  INNODB_SYS_TABLESTATS	INNODB_TABLESTATS
  INNODB_SYS_VIRTUAL	INNODB_VIRTUAL

  
  

  MySQL 8.0.3 以上にアップグレードした後、以前の InnoDB INFORMATION_SCHEMA ビュー名を参照するスクリプトを更新します。

• MySQL にバンドルされている「zlib ライブラリ」バージョンは、バージョン 1.2.3 からバージョン 1.2.11 に引き上げられました。

  zlib 1.2.11 の zlib compressBound() 関数は、zlib version 1.2.3 の場合よりも一定のバイト長を圧縮するために必要なバッファーサイズの見積りを少し大きく返します。 compressBound() 関数は、圧縮 InnoDB テーブルの作成時または圧縮 InnoDB テーブルへの行の挿入および更新時に許可される最大行サイズを決定する InnoDB 関数によってコールされます。 その結果、以前のリリースで成功した最大行サイズに非常に近い行サイズの CREATE TABLE ... ROW_FORMAT=COMPRESSED、INSERT および UPDATE 操作が失敗する可能性があります。 この問題を回避するには、アップグレードの前に、MySQL 8.0 テストインスタンスで大きい行を含む圧縮 InnoDB テーブルの CREATE TABLE ステートメントをテストします。

• --innodb-directories 機能の導入により、絶対パスまたはデータディレクトリ外の場所で作成された file-per-table および一般的なテーブルスペースファイルの場所を innodb_directories 引数値に追加する必要があります。 そうしないと、InnoDB はリカバリ中にこれらのファイルを検出できません。 テーブルスペースファイルの場所を表示するには、INFORMATION_SCHEMA.FILES テーブルをクエリーします:

  SELECT TABLESPACE_NAME, FILE_NAME FROM INFORMATION_SCHEMA.FILES \G

• undo ログはシステムテーブルスペースに存在できなくなりました。 MySQL 8.0 では、undo ログはデフォルトで 2 つの undo テーブルスペースに存在します。 詳細は、セクション15.6.3.4「undo テーブルスペース」を参照してください。

  MySQL 5.7 から MySQL 8.0 にアップグレードする場合、MySQL 5.7 インスタンスに存在する undo テーブルスペースは削除され、2 つの新しいデフォルト undo テーブルスペースに置き換えられます。 デフォルトの undo テーブルスペースは、innodb_undo_directory 変数で定義された場所に作成されます。 innodb_undo_directory 変数が定義されていない場合、undo テーブルスペースはデータディレクトリに作成されます。 MySQL 5.7 から MySQL へのアップグレード 8.0 では、MySQL 5.7 インスタンスの undo テーブルスペースが空であることを保証する低速な停止が必要であり、安全に削除できます。

  以前の MySQL 8.0 リリースから MySQL 8.0.14 以降にアップグレードする場合、2 より大きい innodb_undo_tablespaces 設定の結果としてアップグレード前インスタンスに存在する undo テーブルスペースは、ユーザー定義 undo テーブルスペースとして扱われ、アップグレード後に ALTER UNDO TABLESPACE および DROP UNDO TABLESPACE 構文を使用してそれぞれ非アクティブ化および削除できます。 MySQL 8.0 リリースシリーズ内のアップグレードでは、常に低速な停止が必要になるわけではありません。つまり、既存の undo テーブルスペースに undo ログが含まれている可能性があります。 したがって、既存の undo テーブルスペースはアップグレードプロセスによって削除されません。

• 互換性のない変更: MySQL 8.0.17 では、CREATE TABLESPACE ... ADD DATAFILE 句で循環ディレクトリ参照は許可されません。 たとえば、次のステートメントの循環ディレクトリ参照 (/../) は使用できません:

  CREATE TABLESPACE ts1 ADD DATAFILE ts1.ibd 'any_directory/../ts1.ibd';

  Linux には制限の例外があり、前述のディレクトリがシンボリックリンクの場合は循環ディレクトリ参照が許可されます。 たとえば、any_directory がシンボリックリンクの場合、前述の例のデータファイルパスは許可されます。 (データファイルパスを'../'で始めることはできます。)

  アップグレードの問題を回避するには、MySQL 8.0.17 以上にアップグレードする前に、テーブルスペースデータファイルパスから循環ディレクトリ参照を削除します。 テーブルスペースパスを調べるには、INFORMATION_SCHEMA.INNODB_DATAFILES テーブルをクエリーします。

• MySQL 8.0.14 で導入された回帰のため、パーティションテーブルおよび lower_case_table_names=1 を含むインスタンスで、MySQL 8.0.14 から MySQL 8.0.16 への MySQL 5.7 または MySQL 8.0 リリースより前の大/小文字を区別するファイルシステムでのインプレースアップグレードが失敗しました。 失敗の原因は、パーティションテーブルのファイル名に関連する大/小文字の不一致の問題でした。 回帰を導入した修正が元に戻され、MySQL 8.0.14 より前の MySQL 5.7 または MySQL 8.0 リリースから MySQL 8.0.17 へのアップグレードが正常に機能するようになりました。 ただし、回帰は MySQL 8.0.14、8.0.15 および 8.0.16 リリースには引き続き存在します。

  パーティション化されたテーブルが存在し、lower_case_table_names=1 がある場合、バイナリまたはパッケージを MySQL 8.0.17 にアップグレードした後にサーバーを起動すると、大/小文字を区別するファイルシステムでの MySQL 8.0.14、8.0.15 または 8.0.16 から MySQL 8.0.17 へのインプレースアップグレードが次のエラーで失敗します:

  Upgrading from server version version_number with
  partitioned tables and lower_case_table_names == 1 on a case sensitive file
  system may cause issues, and is therefore prohibited. To upgrade anyway, restart
  the new server version with the command line option 'upgrade=FORCE'. When
  upgrade is completed, please execute 'RENAME TABLE part_table_name
  TO new_table_name; RENAME TABLE new_table_name
  TO part_table_name;' for each of the partitioned tables.
  Please see the documentation for further information.

  MySQL 8.0.17 へのアップグレード時にこのエラーが発生した場合は、次の回避策を実行します:

  1. --upgrade=force を使用してサーバーを再起動し、アップグレード操作を強制的に続行します。

  2. 小文字のパーティション名デリミタ (#p#または#sp#を使用して、パーティションテーブルのファイル名を識別します:

     mysql> SELECT FILE_NAME FROM INFORMATION_SCHEMA.FILES WHERE FILE_NAME LIKE '%#p#%' OR FILE_NAME LIKE '%#sp#%';

  3. 識別されたファイルごとに、一時名を使用して関連するテーブルの名前を変更し、テーブルの名前を元の名前に戻します。

     mysql> RENAME TABLE table_name TO temporary_table_name;
     mysql> RENAME TABLE temporary_table_name TO table_name;

  4. パーティションテーブルファイル名の小文字のパーティション名デリミタがないことを確認します (空の結果セットが返されます)。

     mysql> SELECT FILE_NAME FROM INFORMATION_SCHEMA.FILES WHERE FILE_NAME LIKE '%#p#%' OR FILE_NAME LIKE '%#sp#%';
     Empty set (0.00 sec)

  5. 名前を変更した各テーブルで ANALYZE TABLE を実行して、mysql.innodb_index_stats テーブルおよび mysql.innodb_table_stats テーブルのオプティマイザ統計を更新します。

  MySQL 8.0.14、8.0.15 および 8.0.16 リリースには回帰がまだ存在するため、MySQL 8.0.14、8.0.15 または 8.0.16 から MySQL 8.0.17 へのパーティションテーブルのインポートは、lower_case_table_names=1 の大/小文字が区別されるファイルシステムではサポートされていません。 これを試行すると、「「テーブルのテーブルスペースがありません」」エラーが発生します。

• MySQL では、テーブルパーティションのテーブルスペース名およびファイル名を作成する際にデリミタ文字列が使用されます。 次に示すように、「#p#」デリミタ文字列はパーティション名の前に、「#sp#」デリミタ文字列はサブパーティション名の前にあります:

        schema_name.table_name#p#partition_name#sp#subpartition_name
        table_name#p#partition_name#sp#subpartition_name.ibd

  従来、Linux などの大/小文字を区別するファイルシステムではデリミタ文字列は大文字 (#P#および#SP#)、Windows などの大/小文字を区別しないファイルシステムでは小文字 (#p#および#sp#) になっていました。 MySQL 8.0.19 の時点では、デリミタ文字列はすべてのファイルシステムで小文字になります。 この変更により、大/小文字を区別するファイルシステムと大/小文字を区別しないファイルシステムの間でデータディレクトリを移行する際の問題が回避されます。 大文字のデリミタ文字列は使用されなくなりました。

  また、ユーザー指定のパーティション名またはサブパーティション名 (大文字または小文字で指定可能) に基づいて生成されたパーティションテーブルスペース名およびファイル名は、大/小文字を区別しないように lower_case_table_names 設定に関係なく小文字で生成 (および内部的に格納) されるようになりました。 たとえば、テーブルパーティションが PART_1 という名前で作成された場合、テーブルスペース名とファイル名は小文字で生成されます:

        schema_name.table_name#p#part_1
        table_name#p#part_1.ibd

  アップグレード時に、MySQL は必要に応じてチェックおよび変更を行います:

  • 小文字のデリミタとパーティション名を確認するために、ディスクおよびデータディクショナリのパーティションファイル名。

  • 以前のバグ修正で発生した関連する問題のデータディクショナリ内のパーティションメタデータ。

  • 以前のバグ修正で導入された関連する問題の InnoDB 統計データ。

  テーブルスペースのインポート操作中に、小文字のデリミタとパーティション名を確認するために、必要に応じてディスク上のパーティションテーブルスペースファイル名がチェックおよび変更されます。

• MySQL 8.0.21 では、テーブルスペースデータファイルが不明なディレクトリに存在することが判明した場合、起動時または MySQL 5.7 からのアップグレード時にエラーログに警告が書き込まれます。 既知のディレクトリは、datadir、innodb_data_home_dir および innodb_directories 変数で定義されているディレクトリです。 ディレクトリを既知にするには、innodb_directories 設定に追加します。 ディレクトリを既知にすると、リカバリ中にデータファイルを検出できるようになります。 詳細は、クラッシュリカバリ中のテーブルスペースの検出を参照してください。

SQL の変更

• 互換性のない変更: MySQL 8.0.13 では、GROUP BY 句の非推奨の ASC 修飾子または DESC 修飾子は削除されています。 以前に GROUP BY ソートに依存していたクエリーでは、以前の MySQL バージョンとは異なる結果が生成される場合があります。 特定のソート順序を生成するには、ORDER BY 句を指定します。

  GROUP BY 句に ASC または DESC 修飾子を使用する MySQL 8.0.12 以下のクエリーおよびストアドプログラム定義を修正する必要があります。 そうしないと、MySQL 8.0.13 以上のレプリカサーバーにレプリケートされる可能性があるため、MySQL 8.0.13 以上へのアップグレードが失敗することがあります。

• MySQL 5.7 では予約されていなかった一部のキーワードが、MySQL 8.0 では予約されている場合があります。 セクション9.3「キーワードと予約語」を参照してください。 これにより、以前に識別子として使用された単語が不正になる可能性があります。 影響を受けるステートメントを修正するには、識別子の引用符を使用します。 セクション9.2「スキーマオブジェクト名」を参照してください。

• アップグレード後、目的の最適化戦略を達成するためにヒントがまだ必要であることを確認するために、アプリケーションコードで指定されたオプティマイザヒントをテストすることをお薦めします。 オプティマイザの拡張により、特定のオプティマイザヒントが不要になる場合があります。 場合によっては、不要なオプティマイザヒントが対応することもあります。

• 互換性のない変更: MySQL 5.7 では、CONSTRAINT symbol 句なしで InnoDB テーブルの FOREIGN KEY 定義を指定するか、symbol なしで CONSTRAINT キーワードを指定すると、InnoDB で生成された制約名が使用されます。 この動作は MySQL 8.0 で変更され、InnoDB では生成された名前ではなく FOREIGN KEY index_name 値が使用されます。 制約名はスキーマ (データベース) ごとに一意である必要があるため、スキーマごとに一意ではない外部キーインデックス名が原因でエラーが発生しました。 このようなエラーを回避するために、MySQL 8.0.16 では新しい制約のネーミング動作が元に戻され、InnoDB では生成された制約名が再度使用されます。

  InnoDB との一貫性のために、CONSTRAINT symbol 句が指定されていない場合、または CONSTRAINT キーワードが symbol なしで指定されている場合は、MySQL 8.0.16 以上に基づく NDB リリースで生成された制約名が使用されます。 MySQL 5.7 以前の MySQL 8.0 リリースに基づく NDB リリースでは、FOREIGN KEY index_name 値が使用されていました。

  前述の変更により、以前の外部キー制約のネーミング動作に依存するアプリケーションの非互換性が生じる場合があります。