主な変更点
■ Account Management関連
● MySQLユーザーアカウントを作成または更新する時に、ユーザーごとのコメントと属性を設定できるようになりました。ユーザーコメントは、CREATE USERまたはALTER USERステートメントで使用されるCOMMENT句に引数として渡される任意のテキストで構成されます。ユーザー属性は、これら2つのステートメントのいずれかで使用されるATTRIBUTE句に引数として渡されるJSONオブジェクトの形式のデータで構成されます。属性には、JSONオブジェクト表記で有効なキーと値のペアを含めることができます。
例えば、次の2つのステートメントの最初のステートメントは、コメントテキストThis is Bill's user account付きのユーザーアカウントbill@localhostを作成します。2番目のステートメントでは、キーemailを使用して、値がbill@example.comのユーザー属性をこのアカウントに追加します。
CREATE USER 'bill'@'localhost' COMMENT 'This is Bill\'s user account';
ALTER USER 'mary'@'localhost'
ATTRIBUTE '{"email":"bill@example.com"}';
COMMENTまたはATTRIBUTEのいずれか1つのみを同じCREATE USERまたはALTER USERステートメントで使用できます。
ユーザーコメントとユーザー属性は、JSONオブジェクトとして内部的に一緒に保存され、コメントテキストはキーコメントを持つエレメントの値として保存されます。INFORMATION_SCHEMA.USER_ATTRIBUTESテーブルのATTRIBUTE列からユーザーコメントとユーザー属性を取得できます。このデータはJSON形式であるため、MySQLのJSON関数と演算子を使用して操作できます。 JSON_MERGE_PATCH();を使用したように、既存のユーザー属性への変更はその現在の値とマージされます。新しいキーと値のペアが属性に追加され、既存のキーの新しい値が以前の値を上書きします。
特定のキーと値のペアをユーザー属性から削除するためには、ALTER USER user ATTRIBUTE '{"key":null}'を使用します。
参照：Bug #31067575。
■ C API関連
● OpenSSLの推奨事項に従い、Cクライアントライブラリのx509_check_host()およびX509_check_ip_asc()呼び出しは、それぞれ、X509_VERIFY_PARAM_set1_host()およびX509_VERIFY_PARAM_set1_ip_asc()呼び出しに置き換えられました。(Bug #29684791) ● MySQL C APIは、非同期関数の圧縮をサポートするようになりました。これは、mysql_options()関数のMYSQL_OPT_COMPRESSION_ALGORITHMSおよびMYSQL_OPT_ZSTD_COMPRESSION_LEVELオプションが、同期操作だけでなく非同期操作にも影響するようになったことを意味します。
■ コンパイル関連
● サーバービルド用のBoostライブラリの最小バージョンは1.72.0になりました。(Bug #30963985)
■ 設定関連
● tcmallocは、mysqld_safe --malloc-libオプションに対して許可された値ではなくなりました。(Bug #31372027)
■ 接続管理関連
● MySQLサーバーは、通常のクライアント接続用の「メイン」ネットワークインターフェイスをサポートし、オプションで管理クライアント接続用の管理ネットワークインターフェイスをサポートします。以前は、メインインターフェイスと管理インターフェイスは、暗号化された接続の証明書やキーファイルなど、同じTLS設定を使用していました。現在は、管理インターフェース用にTLSマテリアルを個別に設定できるようになりました。 ・特に管理インターフェースに適用される新しい設定パラメーターがあります。 ・ALTER INSTANCE RELOAD TLSステートメントはFOR CHANNEL句で拡張され、TLSコンテキストをリロードするチャネル（インターフェース）を指定できるようにしました。 ・パフォーマンススキーマの新しいtls_channel_statusテーブルは、メインインターフェースおよび管理インターフェースのTLSコンテキストプロパティを公開します。 ・下位互換性のため、管理インターフェースにデフォルト以外のTLSパラメータ値が設定されていない限り、管理インターフェースはメインインターフェースと同じTLSコンテキストを使用します。
■ 非推奨と削除関連
● パーティショニング：インデックスプレフィックスを持つ列は、テーブルのパーティショニングキーの一部としてサポートされていません。以前は、問題の実際の原因を特定しないエラーメッセージでステートメントが失敗した場合、提案されたパーティショニング関数がプレフィックス付きの列のみを使用した場合を除き、そのような列はキーによってパーティション化されたテーブルの作成、変更、またはアップグレード時に参照されると、サーバーによって単純に省略されましたが、この省略が行われたことは示されませんでした。この動作は現在非推奨であり、将来のリリースで削除される可能性があります。提案されたパーティショニングキーでそのような列を使用すると、それらが発生するCREATE TABLEまたはALTER TABLEステートメントが拒否されます。 インデックスプレフィックスを使用する1つ以上の列がパーティショニングキーの一部として指定されている場合、そのような列ごとに警告が生成されるようになりました。さらに、提案されたパーティショニングキーで指定された全ての列がインデックスプレフィックスを使用するためにCREATE TABLEまたはALTER TABLEステートメントが拒否された場合、返されるエラーメッセージでステートメントが成功しなかった理由が明らかになります。これには、パーティショニング関数が提案された列が、空のPARTITION BY KEY()句を使用してテーブルのプライマリキーの列として暗黙的に定義されている場合が含まれます。 参照：Bug #29942014。
■ JSON関連
● JSON_VALUE()関数が追加されました。これにより、JSON列でのインデックスの作成が簡素化されます。JSON_VALUE(json_doc, path RETURNING type)の呼び出しは、CAST( JSON_UNQUOTE( JSON_EXTRACT(json_doc, path) ) AS type)を呼び出すのと同等です。ここで、json_docはJSONドキュメント、pathはそのドキュメント内の単一の値を指すJSONパス式、typeはCAST()と互換性のあるデータタイプです。RETURNING 型はオプションです。戻り値の型が指定されていない場合、JSON_VALUE()はVARCHAR(512)を返します。
JSON_VALUE()は、JSON_TABLE()で使用されるものと同様のON EMPTYおよびON ERROR句もサポートしています。
次に示すように、JSON_VALUE()を使用してJSON列にインデックスを作成できます。
CREATE TABLE inventory(
items JSON,
INDEX i1 ( (JSON_VALUE(items, '$.name' RETURNING VARCHAR(50))) ),
INDEX i2 ( (JSON_VALUE(items, '$.price' RETURNING DECIMAL(5,2))) ),
INDEX i3 ( (JSON_VALUE(items, '$.quantity' RETURNING UNSIGNED)) )
);
items列に'{"name": "hat", "price": "22.95", "quantity": "17"}'のような値が含まれていると仮定すると、これらのインデックスを使用できる次のようなクエリを発行できます。
SELECT items->"$.price" FROM inventory
WHERE JSON_VALUE(items, '$.name' RETURNING VARCHAR(50)) = "hat";
SELECT * FROM inventory
WHERE JSON_VALUE(items, '$.price' RETURNING DECIMAL(5,2)) <= 100.01;
SELECT items->"$.name" AS item, items->"$.price" AS amount
FROM inventory
WHERE JSON_VALUE(items, '$.quantity' RETURNING UNSIGNED) > 500;
■ オプティマイザ関連
● MySQLは、LIMIT句を持つORDER BYまたはGROUP BYクエリに順序付けされたインデックスを使用しようとし、これにより、実行がより高速になると判断した時は常に、オプティマイザによる他の選択が上書きされます。この決定を行うためのアルゴリズムは、データの分散やその他の条件についていくらかの仮定を行うため、常に完全に正しいとは限らず、そのようなクエリに別の最適化を選択すると、パフォーマンスが向上する場合があります。このような状況を処理するために、optimizer_switchシステム変数のprefer_ordering_indexフラグをオフに設定することで、この最適化を無効にできるようになりました。 (Bug #97001、Bug #30348211) ● [NOT] INまたは[NOT] EXISTS述語を持つサブクエリを使用する単一テーブルのUPDATEまたはDELETEステートメントは、多くの場合に、準結合変換またはサブクエリのマテリアライゼーションを利用できるようになりました。これが実行できるのは、ステートメントがLIMITまたはORDER BYを使用しない場合、および、サブクエリで使用されるオプティマイザヒントによってまたはoptimizer_switchサーバーシステム変数の値によって準結合またはサブクエリのマテリアライゼーションが許可される場合です。 オプティマイザトレースにjoin_optimizationオブジェクトが存在するために、適格な単一テーブルのDELETEまたはUPDATEに対して、いつ準結合の最適化またはサブクエリのマテリアライゼーションが使用されるかを確認できます。また、EXPLAIN FORMAT=TREEの出力を確認することにより、変換が実行されていることがわかります。最適化が実行されない場合、これは<not executable by iterator executor>を示し、マルチテーブルステートメントは完全なプランを報告します。 この作業の一環として、半一貫性読み取りが、トランザクションの分離レベルがREPEATABLE READよりも弱い場合に、InnoDBテーブルのマルチテーブルUPDATEによってサポートされるようになりました。(Bug #35794、Bug #96423、Bug #11748293、Bug #30139244) ● optimizer_switchフラグsubquery_to_derivedが追加されました。このフラグがオンに設定されている場合、オプティマイザは適格なスカラーサブクエリを派生テーブルの左外部結合（場合によっては内部結合）に変換します。この最適化は、次の条件を満たすサブクエリに適用できます。 ・1つ以上の集約関数を使用するが、GROUP BYは使用しない。 ・SELECT、WHERE、JOIN、HAVING句の一部である。 ・相関サブクエリではない。 ・非決定的な関数を利用していない。 MIN()またはMAX()を使用するように書き換え可能なANYサブクエリとALLサブクエリも影響を受けません。 subquery_to_derived=onを使用すると、IN、NOT IN、EXISTS、またはNOT EXISTSの引数であり、GROUP BY句を含まないテーブルサブクエリにも最適化を適用できます。 subquery_to_derivedフラグはデフォルトではオフに設定されています。これは大抵パフォーマンスを向上させず、ほとんどの場合の使用目的がテスト目的であるためです。 ● MySQL 8.0.18で行われた作業に基づいて、サーバーは、クエリへのキャストの投入を実行して、文字列データ型を数値型または時間型のデータと比較する時の不一致を回避します。オプティマイザは、数値型と時間型を比較する時と同様に、引数のデータ型と予期されるデータ型が一致しない式や条件内のアイテムツリーにキャスト操作を追加するようになりました。これにより、MySQLの以前のリリースとの下位互換性を維持しながら、文字列型が数値型または時間型と比較されるクエリは、SQL標準に準拠するクエリと同等になります。このようなキャストは、標準の数値比較演算子（=、>=、>、<、<=、<>/!=、<=>）を使用して文字列値が数値または時間値と比較される時は常に実行されるようになりました。 このような暗黙のキャストは、文字列値をDOUBLEにキャストすることによって、文字列型（CHAR、VARCHAR、BINARY、VARBINARY、BLOB、TEXT、ENUM、SET）と数値型（SMALLINT、TINYINT、MEDIUMINT、INT/INTEGER、BIGINT; DECIMAL/NUMERIC; FLOAT、DOUBLE、REAL; BIT）の間で実行されるようになりました。数値がまだDOUBLE型、FLOAT型、または、REAL型でない場合、それもDOUBLEにキャストされます。YEAR値もまた、文字列値と比較される時、DOUBLEにキャストされます（文字列値と同様に）。文字列型とTIMESTAMP値またはDATETIME値とのこのような比較では、引数はDATETIMEとしてキャストされます。文字列型がDATE値と比較される時は、文字列はDATEにキャストされます。 例えば、"SELECT * FROM t1 JOIN t2 ON t1.char_col = t2.int_col"のようなクエリは、"SELECT * FROM t1 JOIN t2 ON CAST(t1.char_col AS DOUBLE) = CAST(t2.int_col AS DOUBLE)"として書き換えられ、実行されます。そして、"SELECT * FROM t1 JOIN t2 ON t1.varchar_col = t2.timestamp_col"は、実行前に"SELECT * FROM t1 JOIN t2 ON CAST(t1.varchar_col AS DATETIME) = CAST(t2.timestamp_col AS DATETIME)"に変換されます。 いつキャストが、EXPLAIN ANALYZE、EXPLAIN FORMAT=JSON、または、EXPLAIN FORMAT=TREEの出力を表示することによって特定のクエリにいつ追加されたかを確認できます。EXPLAIN [FORMAT=TRADITIONAL]も使用可能ですが、この場合、EXPLAINステートメントの実行後に、SHOW WARNINGSを発行して、書き換えられたクエリを表示する必要があります。 この変更により、クエリの結果やパフォーマンスに違いが生じることは想定されていません。
■ パッケージ関連
● RPMおよびDebianパッケージの場合、クライアント側のプラグインはサーバーパッケージからクライアントパッケージに移動されました。さらに、クライアント側のプラグインのデバッグバージョンがテストパッケージに移動されました。(Bug #31123564、Bug #31336340) ● WindowsのMSIパッケージには、レガシーサーバーデータコンポーネントが含まれなくなりました。(Bug #31060177) ● MySQLにバンドルされているlibeventライブラリがバージョン2.1.11にアップグレードされました。(Bug #30926742) ● MySQLにバンドルされているICU（International Components for Unicode）ライブラリがバージョン65.1にアップグレードされました。
■ プラガブル認証
● SASL LDAP認証を実装するMySQL Enterprise Editionのauthentication_ldap_saslプラグインは、複数の認証方法をサポートしますが、ホストシステムの設定によっては、全て利用可能ではない場合があります。新しいAuthentication_ldap_sasl_supported_methodsステータス変数は、サポートされているメソッドを検出できるようにします。その値は、スペースで区切られたサポートされているメソッド名で構成される文字列です。 例: "SCRAM-SHA1 GSSAPI"
■ セキュリティ関連
● OpenSSLライブラリがバンドルされているプラットフォームについては、MySQLサーバーのリンクされたOpenSSLライブラリがバージョン1.1.1gに更新されました。新しいOpenSSLバージョンで修正された問題は、https：//www.openssl.org/news/cl111.txtおよびhttps://www.openssl.org/news/vulnerabilities.htmlで説明されています。(Bug #31296697) ● 以前は、LOAD DATAステートメントのLOCALデータロード機能は、クライアントにアクセス可能な全てのファイルに対してそれを有効にするか、完全に無効にすることによってのみ、クライアント側で制御できました。mysql_options() C API関数の新しいMYSQL_OPT_LOAD_DATA_LOCAL_DIRオプションにより、クライアントは指定されたディレクトリにあるファイルへのLOCALデータロードを制限できます。
■ テストスイート関連
● mysql-test-run.plは、コマンドオプションの一意のプレフィックスを受け入れなくなりました。完全なオプション名を指定する必要があります。(Bug #31390127) ● MySQLテストは、googletest 1.10.0を使用するように更新されました。(Bug #31364750) ● mysql-test-run.plは、使用可能なポート範囲を検索する時に除外するポートの範囲を指定するための--mtr-port-excludeオプションをサポートするようになりました。MTR_PORT_EXCLUDE環境変数を設定して、同じ効果を実現することも可能です。(Bug #30809607) ● CTRL+C（SIGINT）の受信時に中止することに加えて、mysql-test-run.plはその時点までに失敗したテストケースのリストも表示するようになりました。(Bug #30407014)
■ Xプラグイン関連
● ドキュメント全体を参照するためにドル記号（$）が使用された場合、Xプラグインは、それが使用されたコンテキストに応じて参照を異なる方法で処理しました。これは現在標準化されています。(Bug #31374713) ● グローバルSQLモードの特定の設定では、Xプラグインの認証プロセスが正しいユーザーパスワードを受け入れることができませんでした。認証プロセスは、一貫性を確保するために、グローバルSQLモードの設定から独立して動作するようになりました。(Bug #31086109)
■ 追加・変更された機能
● 重要な変更：デフォルトでは、レプリケーションソースサーバーは、システムログbinlog_checksumで指定されているように（デフォルトはCRC32に設定）、各イベントのチェックサムをバイナリログに書き込みます。以前は、グループレプリケーションはバイナリログ内のチェックサムの存在をサポートしていなかったため、グループメンバーになるサーバーインスタンスを設定する時にbinlog_checksumをNONEに設定する必要がありました。この要件は削除され、デフォルトを使用できるようになりました。binlog_checksumの設定は、グループの全てのメンバーで同じである必要はありません。
グループレプリケーションは、group_replication_applierチャネルの着信イベントを検証するためにチェックサムを使用しないことに注意してください。これは、イベントが複数のソースからそのリレーログに書き込まれ、それが元のサーバーのバイナリログに実際に書き込まれる前（チェックサムが生成される時）であるためです。チェックサムは、group_replication_recoveryチャネルおよびグループメンバーの他のレプリケーションチャネルのイベントの整合性を検証するために使用されます。
● パフォーマンス：16進数の文字列をそのバイナリ表現にマッピングするためのルックアップテーブルを導入することにより、UNHEX()関数の実装を改善しました。この変更により、テストでは関数の実行が8倍以上高速化されます。(Bug #31173103)
● InnoDB：ALTER INSTANCE {ENABLE|DISABLE} INNODB REDO_LOG構文を使用して、REDOロギングを有効および無効にできるようになりました。この機能は、新しいMySQLインスタンスにデータをロードするためのものです。REDOロギングを無効にすると、REDOログの書き込みが回避されるため、データの読み込みが高速化されます。
新しいINNODB_REDO_LOG_ENABLE権限により、REDOロギングの有効化と無効化が許可されます。
新しいInnodb_redo_log_enabledステータス変数を使用すると、REDOログのステータスを監視できます。
● InnoDB：ビジーシステムでUNDOテーブルスペースをトランケートすると、古いUNDOテーブルスペースページをバッファプールから削除し、新しいUNDOテーブルスペースの最初のページをディスクにフラッシュする関連フラッシュ操作により、パフォーマンスに影響を与える可能性がありました。この問題に対処するために、このフラッシュ操作が削除されました。
古いUNDOテーブルスペースページは、最も長い間使われていない時に受動的に解放されるか、次の完全なチェックポイントで削除されます。新しいUNDOテーブルスペースの最初のページは、トランケート操作中にディスクにフラッシュされる代わりにREDOログに記録されるようになりました。これにより、UNDOテーブルスペースのトランケート操作の永続性も向上します。
UNDOテーブルスペースのトランケート操作の数が多過ぎることによって引き起こされる潜在的な問題を回避するために、チェックポイント間の同じUNDOテーブルスペースでのトランケート操作は現在64までに制限されています。その制限を超えた場合、UNDOテーブルスペースを引き続き非アクティブにできますが、次のチェックポイントの後までトランケートされません。
機能していないUNDOトランケートフラッシュ操作に関連付けられたINNODB_METRICSカウンターが削除されました。削除されたカウンターには、undo_truncate_sweep_count、undo_truncate_sweep_usec、undo_truncate_flush_count、undo_truncate_flush_usecが含まれます。
● InnoDB：起動時に、テーブルスペースファイルが別の場所に移動された場合、InnoDBはデータディクショナリに保存されているテーブルスペースファイルパスに対して既知のテーブルスペースファイルのパスを検証します。新しいinnodb_validate_tablespace_paths変数を使用すると、テーブルスペースパスの検証を無効にできます。この機能は、テーブルスペースファイルが移動されない環境を対象としています。テーブルスペースパス検証を無効にすると、テーブルスペースファイルが多数あるシステムでの起動時間が改善されます。
● InnoDB：DATA DIRECTORY句を使用してデータディレクトリの外部に作成されたテーブルとテーブルパーティションのデータファイルは、InnoDBが認識しているディレクトリに制限されるようになりました。この変更により、データベース管理者はテーブルスペースデータファイルの作成場所を制御でき、データファイルをリカバリ中に確実に見つけることができます。
一般およびfile-per-tableのテーブルスペースデータファイル（.ibdファイル）は、UNDOテーブルスペースディレクトリ（innodb_undo_directory）がInnoDBに直接認識されていない限り、UNDOテーブルスペースディレクトリに作成できなくなりました。
既知のディレクトリは、datadir、innodb_data_home_dir、innodb_directories変数によって定義されたディレクトリです。
file-per-tableのテーブルスペースにあるInnoDBテーブルをトランケートすると、既存のテーブルスペースが削除され、新しいテーブルスペースが作成されます。MySQL 8.0.21以降、InnoDBは、テーブルスペースが以前のバージョンで作成され、現在のテーブルスペースディレクトリが不明な場合、デフォルトの場所に新しいテーブルスペースを作成し、エラーログに警告を書き込みます。TRUNCATE TABLEで現在の場所にテーブルスペースを作成するためには、TRUNCATE TABLEを実行する前にinnodb_directories設定にディレクトリを追加します。
● InnoDB：テーブルおよび行のリソースのためにロックキューへのアクセスを必要とする操作の同時実行性を改善するために、ロックシステムミューテックス（lock_sys->mutex）はシャードされたラッチに置き換えられ、ロックキューはテーブルとページのロックキューシャードにグループ化されました。各シャードは専用のミューテックスによって保護されています。以前は、単一ロックシステムミューテックスが全てのロックキューを保護しましたが、これは同時実行性の高いシステムでの競合のポイントでした。新しいシャード実装により、ロックキューへのより詳細なアクセスが可能になります。
ロックシステムミューテックス（lock_sys->mutex）は、次のシャードされたラッチで置き換えられました。
・64個の読み書きロックオブジェクト（rw_lock_t）からなるグローバルラッチ（lock_sys->latches.global_latch）。個々のロックキューへのアクセスは、共有グローバルラッチとロックキューシャードのラッチを必要とします。全てのロックキューへのアクセスを必要とする操作は、全てのテーブルとページのロックキューシャードをラッチする排他的なグローバルラッチを取得します。
・テーブルシャードラッチ（lock_sys->latches.table_shards.mutexes）。これは、ミューテックス512個の配列として実装され、それぞれのミューテックスはテーブルロックキューシャード512個の1つのみに使用されます。
・ページシャードラッチ（lock_sys->latches.page_shards.mutexes）。これは、ミューテックス512個の配列として実装され、それぞれのミューテックスはページロックキューシャード512個の1つのみに使用されます。
シングルロックシステムミューテックスを監視するためのパフォーマンススキーマのwait/synch/mutex/innodb/lock_mutexインストゥルメントは、新しいグローバルラッチ、テーブルシャードラッチ、ページシャードラッチを監視するためのインストゥルメントに置き換えられました。
・wait/synch/sxlock/innodb/lock_sys_global_rw_lock
・wait/synch/mutex/innodb/lock_sys_table_mutex
・wait/synch/mutex/innodb/lock_sys_page_mutex
● 以前は、--disabled-storage-enginesオプションは、オプション値にリストされているストレージエンジンの周りのスペースを無視しませんでした。エンジン名の周りのスペースは無視されるようになりました。(Bug #31373361、Bug #99632)
● 新しいHANDLE_FATAL_SIGNALS CMakeオプションを使用すると、Address SanitizerビルドとUndefined Behavior SanitizerビルドがMySQL内部関数ではなくサニタイザーランタイムライブラリを使用して致命的な信号を処理するかどうかを設定できます。オプションのデフォルトは、非サニタイザービルドの場合はオン、サニタイザービルドの場合はオフです。オプションがOFFの場合、デフォルトのアクションは、内部関数ではなく、SIGBUS、SIGILL、SIGSEGVに使用されます。(Bug #31068443)
● ROLLUPと組み合わせて、（エイリアスを介して）GROUP BYで2回以上繰り返される列を使用すると、MySQL 5.7とは異なる動作がありました。例：
SELECT a, b AS a, COUNT(*) FROM t1 GROUP BY a, b WITH ROLLUP;
このようなクエリの動作は、MySQL 5.7により一致するように変更されました。ただし、動作は将来的に再度変更されるか、そのようなクエリが違法になる可能性があるため、これらは避けるべきです。(Bug #30921780、Bug #98663)
● MySQL Server Dockerコンテナは、クライアントセッション内でのサーバーの再起動をサポートするようになりました（これは、例えば、クライアントによっRESTARTステートメントが実行された時、または、InnoDBクラスターインスタンスの設定中に発生します）。この重要な機能を有効にするためには、docker runオプション --restartを値 on-failureに設定してコンテナを起動する必要があります。(Bug #30750730)
● EXPLAIN ANALYZEがFORMATオプションをサポートするようになりました。現在、TREEのみがサポートされている形式です。(Bug #30315224)
● read_onlyまたはsuper_read_onlyが有効になっている場合、ALTER INSTANCE ROTATE INNODB MASTER KEYは許可されなくなりました。(Bug #30274240)
● LOAD XMLは、インポートされるXMLファイルのCDATAセクションをサポートするようになりました。(Bug #98199、Bug #30753708)
● Xプラグインのmysqlx_bind_addressシステム変数が、MySQLサーバーのbind_addressシステム変数と同様に複数のIPアドレスを受け入れるようになり、Xプラグインが複数のネットワークソケットでTCP/IP接続をリッスンできるようになりました。
動作の重要な違いは、MySQLサーバーの場合、アドレスのリストにエラーがあるとサーバーは起動しませんが、Xプラグイン（これは必須のプラグインではありません）はこれを行わないことです。Xプラグインでは、リストされたアドレスの1つが解析できない場合、または、Xプラグインがそれにバインドできない場合、そのアドレスはスキップされ、エラーメッセージがログに記録され、Xプラグインは残りの各アドレスへのバインドを試みます。XプラグインのMysqlx_addressステータス変数は、バインドが成功したリストのアドレスのみを表示します。リストされたアドレスのいずれもバインドが成功しない場合、Xプラグインは、Xプロトコルを使用できないことを示すエラーメッセージをログに記録します。
● アトミックDDLをサポートするストレージエンジンで、行ベースのレプリケーションが使用されている場合、CREATE TABLE ... SELECTステートメントが1つのトランザクションとしてバイナリログに記録されるようになりました。以前は、テーブルを作成するトランザクションとデータを挿入する別のトランザクションの2つのトランザクションとして記録されていました。この変更により、CREATE TABLE ... SELECTステートメントが行ベースのレプリケーションで安全になり、GTIDベースのレプリケーションで使用できるようになりました。
● ENGINE_ATTRIBUTEおよびSECONDARY_ENGINE_ATTRIBUTEオプションがCREATE TABLE、ALTER TABLE、CREATE INDEX構文に追加されました。ENGINE_ATTRIBUTEオプションもCREATE TABLESPACEとALTER TABLESPACE構文に追加されました。テーブル、列、インデックス、テーブルスペースのストレージエンジン属性を定義できる新しいオプションは、将来の使用のために保存されます。
次のINFORMATION_SCHEMAテーブルは、テーブル、列、インデックス、テーブルスペースのストレージエンジン属性に問い合わせるために追加されました。値は、データディクショナリに保存されます。テーブルは将来の使用のために保存されます。
・INFORMATION_SCHEMA.TABLES_EXTENSIONS
・INFORMATION_SCHEMA.COLUMNS_EXTENSIONS
・INFORMATION_SCHEMA.TABLE_CONSTRAINTS_EXTENSIONS
・INFORMATION_SCHEMA.TABLESPACES_EXTENSIONS
● グループレプリケーションのグループメンバーは、参加しているメンバーが分散リカバリ中の状態転送のために接続するために使用できるIPアドレスのリストを公表できるようになりました。以前は、この目的とクライアントトラフィックのために、既存のメンバーの標準SQLクライアント接続が使用されました。代わりに、分散リカバリエンドポイントを公表することで、ネットワークインフラストラクチャの分散リカバリトラフィック（リモートクローニング操作とバイナリログからの状態転送を含む）の制御が向上します。メンバーの分散リカバリエンドポイントのリストは、新しいgroup_replication_advertise_recovery_endpointsシステム変数を使用して指定され、SQLクライアント接続が分散リカバリに使用された場合と同じSSL要件が適用されます。
● MySQLサーバーのデフォルトのログレベルでは、情報ログメッセージは省略されます。このメッセージには、以前は、グループメンバーシップの変更など、エラーではない状況であったグループレプリケーションの重要なライフサイクルイベントが含まれていました。レプリケーショングループの重要なイベントに関するメッセージは、システムメッセージとして再分類されるようになったため、それらはサーバーのログレベルに関係なく、常にサーバーのエラーログに表示されます。したがって、オペレーターは、レプリケーショングループ内のサーバーのメンバーシップの完全な履歴を確認できます。また、グループ通信レイヤーのソケットバインドエラーは、情報からエラーメッセージに再分類されました。
● USER、PASSWORD、DEFAULT_AUTHオプションを使用して、START GROUP_REPLICATIONステートメントで分散リカバリ用のユーザー認証情報を指定できるようになりました。これらの認証情報は、group_replication_recoveryチャネルでの分散リカバリに使用されます。START GROUP_REPLICATIONでユーザー認証情報を指定すると、認証情報はメモリにのみ保存され、STOP GROUP_REPLICATIONステートメントまたはサーバーのシャットダウンによって削除されます。これらの認証情報は、レプリケーションメタデータリポジトリに保存されているCHANGE MASTER TOステートメントを使用して設定されたユーザー認証情報を置き換えることができ、したがって、不正なアクセスからグループレプリケーションサーバーを保護するのに役立ちます。
ユーザー認証情報を提供する新しい方法は、サーバーの起動時にグループレプリケーションを自動的に開始することと互換性がありません。ユーザー認証情報がCHANGE MASTER TOステートメントを使用して以前に設定されている場合、START GROUP_REPLICATIONで指定する認証情報がこれらの認証情報よりも優先されます。ただし、レプリケーションメタデータリポジトリからの認証情報は、START GROUP_REPLICATIONがユーザー認証情報なしで指定されている場合に使用されます。これは、group_replication_start_on_bootシステム変数がONに設定されている場合（分散リカバリのリモートクローン作成操作後を含む）に、自動起動時に発生します。START GROUP_REPLICATIONでユーザー認証情報を指定することのセキュリティ上のメリットを得るためには、group_replication_start_on_bootがOFF（デフォルトはON）に設定されていることを確認し、CHANGE MASTER TOステートメントを使用して、以前にgroup_replication_recoveryチャネルに設定されたユーザー認証情報をクリアします。
● group_replication_message_cache_sizeシステム変数で指定された、グループレプリケーションのXComメッセージキャッシュの最大サイズの最小設定が、約1GBから134217728バイト、または約128 MBに削減されました。このサイズ制限はキャッシュに保存されたデータにのみ適用され、キャッシュ構造は追加の50 MBのメモリを必要とすることに注意してください。全てのグループメンバーに同じキャッシュサイズ制限を設定する必要があります。以前は最小設定でもあった1GBのデフォルトのXComメッセージキャッシュサイズは、変更されていません。
使用可能なメモリの量が制限されており、ネットワーク接続が良好であるホストでのデプロイを可能にするために、より小さいメッセージキャッシュサイズが提供されています。ホストが不安定なネットワーク上にある場合、group_replication_message_cache_sizeの設定を非常に低くすることは推奨されません。メッセージキャッシュが小さいと、接続が一時的に失われた後にグループメンバーが再接続することが難しくなるためです。メンバーが一時的に不在の時に交換されたメッセージが、最大サイズの制限に達したために他のメンバーのXComメッセージキャッシュから削除された場合、メンバーはメッセージキャッシュを使用して再接続できません。メンバーは今でもオペレーターの介入なしにこの方法で再結合できますが、分散リカバリを通じてトランザクションを取得するためにグループを離れて再結合する必要があります。これは、メッセージキャッシュを使用するよりも遅いプロセスです。
MySQL 8.0.21以降では、メンバーがグループから追放される前に、デフォルトで5秒の追放タイムアウトが追加されることに注意してください（group_replication_member_expel_timeoutシステム変数で指定）。したがって、このデフォルト設定では、XComメッセージキャッシュは、グループによって交換されたメッセージを、以前のように5秒の期間（最初の5秒間の検出期間のみ）ではなく、10秒の期間（追放タイムアウトと最初の5秒の検出期間）で保存する必要があります。
● group_replication_member_expel_timeout変数は、Group Replicationのグループメンバーが、エラーが発生したと疑われるメンバーをグループから追放する前に、疑いを持った後に待機する時間を秒単位で指定します。疑いを持つ前の最初の5秒の検出期間は、この時間の一部としてカウントされません。
以前は、group_replication_member_expel_timeoutで指定される待機期間はデフォルトで0でした。これは、5秒の検出期間が終了した直後に、疑わしいメンバーは追放の責任を負うことを意味していました。ユーザーのフィードバックに従って、待機期間はデフォルトで5秒になり、グループと関わりがなくなったメンバーにはグループに再び接続するために合計10秒が与えられます。この時間内にメンバーが再接続した場合、メンバーは、グループから追放されて再参加するために自動再参加手順または手動のオペレーター介入を必要とするのではなく、XComメッセージキャッシュから失われたメッセージを回復してONLINE状態に自動的に戻ることができます。
メンバーが追放される前に以前のデフォルト時間（5秒間の検出期間のみ）で予想されるメッセージの量を参照してXComメッセージキャッシュのサイズを前もって調整した場合、新しい追放タイムアウトを考慮してgroup_replication_message_cache_size設定を増やします。これはデフォルトの時間を10秒に2倍にします。新しいデフォルトの追放タイムアウトにより、アクティブなグループメンバーでGCSからの警告メッセージが表示されるようになり、現在到達できないメンバーによるリカバリに必要とされる可能性のあるメッセージがメッセージキャッシュから削除されたことが示されます。このメッセージは、メンバーがメッセージキャッシュを使用して再接続する必要があったことと、メンバーが追放される前の現在の待機期間をサポートするためにはキャッシュサイズが十分でない可能性があることを示しています。
● グループレプリケーションの自動再参加機能がデフォルトで有効になりました。MySQL 8.0.16から使用可能なgroup_replication_autorejoin_triesシステム変数は、追放されたメンバー、または、到達不能な過半数タイムアウトに達したメンバーに、グループへの再参加を自動的に試行させます。このシステム変数は、元はデフォルトで0だったため、自動再参加は有効ではありませんでしたが、現在デフォルトは3になりました。つまり、メンバーがその追放タイムアウトまたは到達不可能な過半数タイムアウトの場合にグループへの再参加を3回試行します。各試行の間、メンバーは5分間待機します。メンバーが再参加または停止することなく指定された試行回数を使い果たした場合、メンバーはgroup_replication_exit_state_actionシステム変数で指定されたアクションに進みます。
自動再参加機能により、特に一時的なネットワークの問題がかなり一般的である場合、メンバーをグループに戻すための手動介入の必要性が最小限に抑えられます。自動再参加試行中および各試行の間、メンバーはsuper read onlyモードのままで、書き込みを受け入れません。ただし、読み取りはそのメンバーに対して行うことは可能ですが、時間の経過とともに読み取りが古くなる可能性が高まります。メンバーをオフラインにするために介入したい場合、STOP GROUP_REPLICATIONステートメントを使用するか、サーバーをシャットダウンすることにより、メンバーをいつでも手動で停止できます。一定期間読み取りが古くなる可能性を許容できない場合、group_replication_autorejoin_triesシステム変数を0に設定します。この場合、メンバーがグループから追放されるか、到達不能な過半数タイムアウトに到達する時は常に、オペレーターの介入が必要になります。
■ 主なバグ修正
● InnoDB：JSON配列の列へのGROUP BY操作により、正しくない型キャストが原因で、MySQLのUBSanビルドでエラーが発生しました。(Bug #31451475)
● InnoDB：いくつかのInnoDBエラーログメッセージがシンボリック値なしで定義されました。(Bug #31401028)
● InnoDB：二重書き込みフラッシュおよび同期操作に関連するデータファイル書き込みエラーの後、単一ページ書き込みのファイルセグメントが解放されませんでした。(Bug #31370227)
● InnoDB：UNDOテーブルスペースの切り捨てが切り捨て操作の前後で同じスペースIDを使用した時にアクセスされたコードは、削除されました。このシナリオは発生しなくなりました。切り捨てられたUNDOテーブルスペースは、スペースIDが異なる新しいUNDOテーブルスペースデータファイルに置き換えられます。(Bug #31354435)
● InnoDB：UNDOテーブルスペースの予約済みスペースIDの範囲が、UNDOテーブルスペースごとに512から400000に増加しました。(Bug #31340834)
● InnoDB：ddl_logテーブルへのログの挿入中に発生したエラーが返されなかったので、操作が成功したように見えました。そして、トランザクションはテーブルスペース暗号化操作の実行中に登録されませんでした。(Bug #31236217)
● InnoDB：lob::purge()関数は、挿入操作が削除マークが付いたレコードを変更する時に生成されるUNDOログレコードタイプ（TRX_UNDO_UPD_DEL_REC）のLOBを正しく解放しませんでした。(Bug #31222046、Bug #99339)
● InnoDB：破棄されたパーティションを再構築しようとした後にシャットダウンエラーが発生しました。(Bug #31215415)
● InnoDB：ディレクトリまたはファイルパスを取得する内部get_real_path()関数は、パスがファイルであるかディレクトリであるかを判断する前に末尾のセパレーターを取り除くように修正されました。さらに、パスが存在しないか、ファイルかサブディレクトリとして識別できない場合、関数は、ベース名に3文字のサフィックスがある場合、パスがファイルであると想定するようになりました。(Bug #31215160)
● InnoDB：テーブルスペース関連のエラーメッセージが修正されました。(Bug #31205520、Bug #31205441)
● InnoDB：潜在的なコンパイルの問題を回避するために、__attribute__((const))よび__attribute__((pure))属性が内部InnoDB関数から削除されました。(Bug #31153123)
● InnoDB：ヒストグラムサンプリングの読み取りスレッドを生成する時に並列読み取りスレッドの制限が守られず、アサーションエラーが引き起こされました。(Bug #31151218)
● InnoDB：ヒストグラム統計情報の生成のためにレコードをサンプリングする時、トランザクション読み取りビューはチェックされませんでした。(Bug #31151077)
● InnoDB：ラッチが別のスレッドによって保持されているため、I/O完了ルーチンはLRUリストミューテックスを取得できませんでした。(Bug #31128739)
● InnoDB：アタッチ可能なトランザクションスレッドが、メインスレッドによってすでに予約されているInnoDBチケットを要求したため、デッドロックが発生しました。さらに、サーバーはこのデッドロックシナリオでKILLステートメントに応答できませんでした。(Bug #31090777)
● InnoDB：モジュール所有者として定義されたカウンターのINNODB_METRICSテーブルのAVG_COUNT_RESET値がNULLを報告しました。METRIC_AVG_VALUE_RESETフィールドが誤ってNULLとしてマークされました。(Bug #31084706、Bug #98990)
● InnoDB：起動時に、UNDOテーブルスペースの切り捨て操作中の予期しない停止に続いて、一部のロールバックセグメントヘッダーページが破損していることが判明しました。ヘッダーページの書き込み中にロールバックセグメントヘッダーページの暗号化が開始されたため、予想どおり、一部のヘッダーページは暗号化されませんでした。(Bug #31045160)
● InnoDB：ロックシステム（lock_sys）コードのさまざまな側面がリファクタリングされ、lock_sys、lock_rec_block_validate()およびlock_test_prdt_pacge_lock()関数の問題が修正されました。lock_rec_block_validate()関数が別の関数を繰り返し呼び出したため、特定の状況下でロックが検証されない可能性がありました。実装には、潜在的な2次の時間の複雑さもありました。lock_test_prdt_page_lock()関数は、意図したとおりに全てのロックを反復しませんでした。(Bug #31001732)
● InnoDB：temptable_max_ramしきい値を超えた後にメモリマップファイルを使用すると、パフォーマンスが低下しました。(Bug #30952983、Bug #98739)
● InnoDB：デバッグモードでは、COMPRESSION句が正しく定義されていないテーブルでのDROP TABLE操作でエラーが発生しました。InnoDBは、適切な処理のために呼び出し元にエラーを返しませんでした。(Bug #30899683、Bug #98593)
● InnoDB：履歴リストの長さがゼロに近づくと、パージスレッドアクティビティが過剰になり、CPUリソースが浪費され、ミューテックスの競合が発生しました。(Bug #30875956)
● InnoDB：MySQL 8.0.18で導入されたリグレッションは、INFORMATION_SCHEMA.INNODB_COLUMNSクエリのパフォーマンスに影響しました。スキーマおよびテーブルデータディクショナリオブジェクトは、パーティションの列情報を取得するために繰り返しフェッチされました。(Bug #30837086、Bug #98449)
参照：この問題は、Bug #93033、Bug #28869903のリグレッションです。
● InnoDB：.cfgファイルを使用したALTER TABLE ... IMPORT TABLESPACE操作が“Incorrect key file for table”というエラーで失敗しました。row_import::m_flagsメンバーは初期化されませんでした。(Bug #30830441)
● InnoDB：パーティションの破棄後に実行されたDROP TABLE操作は、関連するデータファイルを削除せず、DROP DATABASEはデータベースディレクトリを削除できなかったことを示すエラーで失敗しました。MySQL 5.7からMySQL 8.0へのアップグレードもまた、破棄されたパーティションを持つパーティションテーブルが存在する場合に失敗しました。DISCARD属性がデータディクショナリのパーティションオブジェクトではなくテーブルオブジェクトに適用されたため、全てのパーティションが破棄されたように見えました。(Bug #30818917)
● InnoDB：サーバーが“ibuf cursor restoration fails”エラーで断続的に失敗した。(Bug #30770380、Bug #91033)
● InnoDB：あるテーブルから別のテーブルにデータをコピーするALTER TABLE操作が“Out of range value for column”エラーを返しました。複数行の挿入操作に必要なAUTO_INCREMENT行の数を追跡するカウンターが、一括挿入操作の後に常にゼロに戻されていませんでした。(Bug #30765952、Bug #98211)
● InnoDB：内部TempTable records_in_range()ハンドラー関数には、デバッグビルドでアサーションエラーを引き起こしたDBUG_ABORT()コールが含まれ、一部のクエリでは通常のビルドで空の結果セットが含まれていました。(Bug #30716037)
● InnoDB：btr_cur_pessimistic_update()関数は、lob::purge()呼び出しによって引き起こされるカーソル位置の変更を処理できませんでした。(Bug #30712878)
● InnoDB：DELETE IGNORE操作中に型変換エラーが発生し、アサーションエラーが発生しました。JSON値が期待された値に変換されませんでした。(Bug #30664660)
● InnoDB：パージ操作でnull LOB参照が発生し、アサーションエラーが引き起こされました。(Bug #30658887)
● InnoDB：TempTableストレージエンジンからメモリの割り当てを解除する時にチャンクサイズが正しく計算されなかったため、SELECT DISTINCTクエリのパフォーマンスが低下しました。(Bug #30562964)
● InnoDB：スレッドプールプラグインの使用中にTempTableストレージエンジンでセグメンテーションエラーが発生しました。TempTableスレッドローカル変数は、単一のクライアント接続によって発行されたステートメントの異なるスレッドの使用と互換性がありませんでした。スレッドローカル変数の使用は、スレッドの存続期間中割り当てられたままのスレッドローカル変数によって使用されるメモリが原因で、メモリの過剰消費にもつながります。これらの問題に対処するために、スレッドローカル変数はキャッシュメカニズムに置き換えられました。(Bug #30050452、Bug #31116036、Bug #99136)
● InnoDB：致命的な“page still fixed or dirty”エラーがシャットダウン中に発生しました。(Bug #29759555、Bug #95285)
参照：この問題は、Bug #330065518のリグレッションです。
● パーティショニング：ORDER BYを使用したパーティションテーブルに対するクエリは、次の条件下で順序付けされない結果を返しました。
・テーブルには、いずれかの列に接頭辞が付いた複合インデックスがあった。
・クエリのWHERE句に、接頭辞付きの列に等価条件が含まれていた。
・接頭辞付きの列が、インデックスの左端の列だった。
・ORDER BYで使用された列が、インデックスの右端の列だった。
・インデックスが、ORDER BYの処理に使用された。
(Bug #84070、Bug #25207522)
● レプリケーション：全てのユーザー接続を制御するgroup_replication_consistencyシステム変数に設定されたグローバル値は、SQL APIを使用したMySQLサーバーモジュールへのグループレプリケーションの内部接続（ユーザー接続と同様の方法で処理される）に適用されます。これにより、グループレプリケーションがgroup_replication_consistencyの使用をエラーとして報告することがあります。例えば、分散リカバリ中にクローンプラグインのステータスを確認する場合です。SQL APIを使用したグループレプリケーションの内部接続は、現在は、整合性レベルEVENTUALを使用するように設定されています。これは、group_replication_consistencyオプションが使用可能になる前の動作と一致し、エラーメッセージを表示しません。(Bug #31303354、Bug #99345)
● レプリケーション：グループの整合性レベル（group_replication_consistencyシステム変数で設定）がBEFOREまたはBEFORE_AND_AFTERに設定されている場合、プライマリフェイルオーバーの場合にデッドロックが発生する可能性がありました。この状況を回避するために、プライマリフェイルオーバーが異なる方法で登録されるようになりました。(Bug #31175066、Bug #98643)
● レプリケーション：Windowsでは、グループレプリケーションが新しい書き込みイベントを待機するためにWindows API関数SleepConditionVariableCSを使用すると、グループレプリケーションが2日以上実行された後、この関数によるCPU使用率が著しく高くなりました。これは、MySQLサーバーインスタンスを再起動することによって修正できますが、その後、以前と同様に時間とともに再び増加しました。これは、SleepConditionVariableCS関数が呼び出された後のタイムアウトを計算するために2つのクロック関数を使用したことが原因でした。これは時間と共に互いに関連して変動し、タイムアウトは徐々に短くなり、関数の呼び出しはより頻繁になります。この問題は、単一クロックからの現在時刻を使用してタイムアウトを計算することにより、Windowsでは修正されました。(Bug #31117930)
● レプリケーション：分散リカバリの実行中にグループレプリケーションが停止した場合、ドナーとして選択されたメンバーのレコードにアクセスしようとすると、メモリの問題が発生する可能性があります。このレコードは、分散リカバリ状態でローカルに保持されるようになりました。(Bug #31069563)
● レプリケーション：グループレプリケーションの分散リカバリにリモートクローニング操作が含まれる場合、これを示すためにサーバーに設定されたフラグは、サーバーインスタンスが再起動されるまで設定されたままになります。以前は、サーバーでグループレプリケーションが停止して再起動した場合、そのフラグにより、グループレプリケーションがgroup_replication_applierチャネルのリレーログファイルをパージしました。これは、クローン化されたデータテーブルとの不一致がないことを確認するためにリモートレプリケーション操作の後に開始する時に必要とされます。パージされたリレーログファイルに未適用のトランザクションがあった場合、その後メンバーを使用してグループをブートストラップすることはできません。しかし、別のメンバーからトランザクションを取得することでグループに正常に参加することはできます。グループレプリケーションは、2回目以降の起動ではフラグを無視し、リモートクローニング操作後に初めて起動された時にのみ、リレーログファイルをパージするようになりました。(Bug #31059680)
● レプリケーション：データの不整合の可能性を回避するために、グループレプリケーションは同じサーバー（同じアドレスで新しい識別子を持つ）の新しいインカネーションがグループに参加するのをブロックしますが、その古いインカネーションはまだメンバーとしてリストされています。以前は、グループレプリケーションのグループコミュニケーションシステム（GCS）は、サーバーへのメッセージの送信を試行している間、サーバーの古いインカネーションへの接続をアクティブとして扱い、ソケットがエラーを返した時に接続が非アクティブであることを認識するだけでした。これはかなりの時間がかかります。その期間中、サーバーの新しいインカネーションはグループに参加できませんでした。なぜなら、既存のメンバーが古いインカネーションへの接続をまだ待っていたので、サーバーに接続しなかったためです。現在、GCSは、メッセージが正常に送信され得る間、サーバーへの接続のみをアクティブとして扱います。ソケットが書き込み可能ではなくなった場合、サーバー接続は非アクティブとして扱われ、積極的に閉じられます。接続のクローズにより、グループメンバーがそのサーバーアドレスへの再接続を試行し、サーバーの新しいインカネーションへの接続が確立され、新しいインカネーションがグループに参加できるようになります。(Bug #30770577)
● レプリケーション：シングルプライマリモードからマルチプライマリモードに切り替える時に、グループレプリケーションは通知をブロードキャストしませんでした。変更はルーティングで使用するために通知されます。(Bug #30738896)
● レプリケーション：レプリケーションのソースサーバーがシャットダウンして再起動すると、そのMEMORYテーブルは空になります。この結果をレプリカに複製するためには、ソースが起動後に特定のMEMORYテーブルを初めて使用する時、そのテーブルのDELETEステートメントをバイナリログに書き込むことによってテーブルが空にされる必要があることをレプリカに通知します。以前は、生成されたDELETEステートメントは現在のセッションのバイナリログステートメントキャッシュに書き込まれていたため、同じGTIDの下で他のステートメントと一緒にログに記録されたり、BEGINステートメントとCOMMITステートメントなしでログに記録されたりしました。また、状況によっては、生成されたDELETEステートメントが、それをトリガーしたトランザクション用のGTIDを使う場合があります。生成されたDELETEステートメントは、付随するBEGINおよびCOMMITステートメントとともにログに記録され、結果のトランザクションはステートメントキャッシュに書き込まれた直後にバイナリログにフラッシュされます。そのため、常に独自のGTIDを受け取り、他のトランザクションとは別に保持されます。(Bug #30527929、Bug #25681518、Bug #77729)
● レプリケーション：MySQL 8.0.14のパッチの後、関数呼び出しは一時テーブルに対する操作を含む場合、binlog_format = MIXEDが設定されていると、ステートメント形式でバイナリログに書き込まれることが可能でした。これにより、CREATE TEMPORARY TABLEステートメントは、関数呼び出しを含む場合、バイナリログに誤って書き込まれました。さらなる分析を受けて、ストアド関数とトリガーの一時テーブルに対する操作は、レプリケーションで問題が発生する可能性が高いため、ステートメント形式でのバイナリロギングに関して安全ではないとマークされるようになりました。binlog_format = MIXEDが設定されている場合、これらの操作は行形式でログに記録されるようになりました。(Bug #30395151、Bug #30320009)
● レプリケーション：グループの指定されたメンバーシップを強制するためのgroup_replication_force_membersシステム変数の設定は、group_replication_force_members操作を実行していたメンバーの追放を別のメンバーがすでに要求している場合に、失敗する可能性がありました。group_replication_force_membersシステム変数で指定された設定を実装する操作により、保留中のグループの再設定が最初に強制実行されました。それらの1つがシステム変数が設定されたメンバーを正常に追放した場合、メンバーに設定された追放タイムアウトが終了したため、その操作はタイムアウトになり、完了できませんでした。この状況を回避するために、グループレプリケーションは、直接、group_replication_force_membersシステム変数で指定された新しい設定の実装に進み、その他の保留中のグループの再設定を無視するようになりました。(Bug #29820966)
● レプリケーション：システム変数binlog_transaction_dependency_trackingおよびbinlog_transaction_dependency_history_sizeを含むデッドロックシナリオに関してMySQL 8.0.14およびMySQL 5.7.25で行われた修正により、トランザクション依存関係の追跡に使用される書き込みセットの履歴が同時更新から保護されないままになるという副作用がありました。書き込みセットの履歴と追跡モードは、アクセスされる時はいつも正しくロックされるようになりました。(Bug #29719364、Bug #95181)
参照：Bug #28511326、Bug #91941。
● レプリケーション：MASTER_USERが空（MASTER_USER=''）として指定されたCHANGE MASTER TOステートメントが発行された場合、ステートメントは成功し、レプリケーションメタデータリポジトリで以前に指定されたユーザー名をクリアしました。ただし、例えばグループレプリケーションチャネルの自動再起動中など、情報がその後リポジトリから読み込まれた場合、デフォルトのユーザー名がチャネルの代わりに使用されることがありました。この問題は現在は修正されているため、MySQL 8.0.21以降は、レプリケーションチャネルを開始するSTART SLAVEステートメントまたはSTART GROUP_REPLICATIONステートメントを使用してユーザー認証情報を常に提供する場合、空のMASTER_USERユーザー名を設定することは有効なアプローチです。このアプローチは、レプリケーションチャネルは再起動するために常にオペレーターの介入を必要としますが、ユーザー認証情報はレプリケーションメタデータリポジトリに記録されないことを意味します。
CHANGE MASTER TOステートメントのドキュメントも修正され、MASTER_USER=''を指定できることを明確にし、空の認証情報を使用してレプリケーションチャネルを開始しようとした場合にのみエラーが発生します。(Bug #27357189)
● レプリケーション：グループレプリケーションの他のグループメンバーへの接続の追跡では、受信接続のみが考慮され、送信接続は考慮されませんでした。これは、例えばファイアウォール設定の問題によって、メンバーAからメンバーBへの送信接続は切断されたが、メンバーBからメンバーAへの受信接続はそのままの場合、メンバーAのメッセージはメンバーBに届いていませんが、メンバーAはメンバーBのステータスをONLINEとして表示します。メンバーBはメンバーAのステータスをUNREACHABLEとして表示します。現在、グループメンバーがアクティブな接続を持つ別のグループメンバーからpingを受信し始めた場合（この場合、メンバーAがメンバーBからpingを受信した場合）、これは接続の問題のインジケーターとして取り扱われます。十分なpingを受信すると、pingの受信者（この場合はメンバーA）によって接続がシャットダウンされるため、接続のステータスは両方のメンバーで一致します。(Bug #25660161、Bug #84796)
● JSON：JSON_TABLE()に渡された式とパスがJSON nullを生成した場合、その関数は必要に応じてSQL NULLを返す代わりにエラーを発生させました。(Bug #31345503)
● JSON：MySQL 5.7および8.0.17より前のMySQL 8.0では、サーバーは、JSONブール値をIS TRUEで直接テストする時に、対応するSQL値に変換しようとしました。次に例を示します。
mysql> CREATE TABLE test (id INT, col JSON);
mysql> INSERT INTO test VALUES (1, '{"val":true}'), (2, '{"val":false}');
mysql> SELECT id, col, col->"$.val" FROM test WHERE col->"$.val" IS TRUE;
+------+---------------+--------------+
| id | col | col->"$.val" |
+------+---------------+--------------+
| 1 | {"val": true} | true |
+------+---------------+--------------+
SQL条件の全ての述語が完全であること（つまり、WHERE値の形式の条件がWHERE 値 <> 0に書き換えられている）、およびWHEREまたはON句のNOT INまたはNOT EXISTS条件が逆結合に変換されることを確保するためにMySQL 8.0.17で行われた作業の結果として、SQLブールコンテキストのJSON値の評価は、JSON整数0に対して暗黙的な比較を実行します。つまり、前に示したクエリは、MySQL 8.0.17以降で次の結果を返します。
mysql> SELECT id, col, col->"$.val" FROM test WHERE col->"$.val" IS TRUE;
+------+----------------+--------------+
| id | col | col->"$.val" |
+------+----------------+--------------+
| 1 | {"val": true} | true |
| 2 | {"val": false} | false |
+------+----------------+--------------+
このような場合、サーバーは警告も提供するようになりました。SQLブールコンテキストのJSON値の評価は、JSON整数0に対して暗黙的な比較を行います。これが望ましくないことの場合、JSON_VALUE RETURNINGを使用してJSONをSQL数値型に変換することを検討してください。結果として、次に示すように、JSON_VALUE()を使用してクエリを書き換えることができるようになりました。
mysql> SELECT id, col, col->"$.val" FROM test
-> WHERE JSON_VALUE(col, "$.val" RETURNING UNSIGNED) IS TRUE;
+------+---------------+--------------+
| id | col | col->"$.val" |
+------+---------------+--------------+
| 1 | {"val": true} | true |
+------+---------------+--------------+
(Bug #31168181)
● JSON：複数値のインデックスを持つテーブルに対するGROUP BYクエリは、サーバーによって常に正しく処理されるとは限りませんでした。(Bug #31152942)
● log_error_servicesが永続化されている場合、起動中に間違ったタイミングでそれが有効になる場合がありました。(Bug #31464539)
● 特定の手動の付与テーブルの変更後のSHOW CREATE USERは、サーバー終了を引き起こす可能性がありました。(Bug #31462844)
● 部分的な取り消しの一部のメモリ内更新は、誤った権限を生成する可能性がありました。(Bug #31430086)
● SET PERSISTを使用してlog_error_verbosityを設定した場合、サーバーの起動中に、InnoDBの初期化に影響を与えるほど早期に有効にはなりませんでした。(Bug #31410674)
● 生成された列式でサブクエリを拒否する前に、パーサーが誤ってアサーションを生成しました。(Bug #31396191)
● このリリースでは、不完全なハッシュ結合（つまり、結合条件のないもの）に対して次の2つのマイクロ最適化が行われます。
a. 不完全なハッシュアンチ結合またはセミ結合の場合、ハッシュテーブルを作成する時にLIMIT 1を追加します。これより多くの行があると結果を変更できないためです。
b. 空ではないハッシュテーブルを使用した不完全なハッシュアンチ結合の場合、外側をスキャンすることを避けてください。
合わせて、これらの変更は、ハッシュアンチ結合への書き換えにより、書き換えられなかったNOT EXISTSクエリはオプティマイザによって実行され、“zero rows found”で置き換えられるというパフォーマンスのリグレッションに対処しました。ネストされたループが代わりに使用される場合に対処するために、NOT EXISTS内の非相関サブクエリはアンチ結合に変換されなくなりました。
この修正は、定数NOT IN（non_correlated_subquery）を使用するサブクエリにも適用されます。(Bug #31376809)
● -DWITH_EDITLINE=systemを使用して設定すると、古いバージョンのライブラリでコンパイルエラーが発生しました。(Bug #31366715)
● 以前のMySQLディストリビューションにバンドルされたlibeditライブラリをアップグレードすると、mysqlクライアントのCTRL+C（SIGINT）が状況によっては次のEnterが有効になることを必要とするというような、そのライブラリを使用したビルドで問題が発生しました。(Bug #31360025)
● AUTO_INCREMENTとDEFAULTの両方の値式を使用して宣言された列は、許可されていない組み合わせですが、ALTER TABLEはAUTO_INCREMENT列に対するSET DEFAULT (expr)操作のエラーを生成できませんでした。(Bug #31331454)
● protocol_compression_algorithmsシステム変数を空の文字列に設定することが可能でしたが、これは許可されなくなりました。(Bug #31326231)
● MySQLサーバーで内部的に使用される検索関数は、引数があいまいな場合、整数-1を返します。これにより、後続の計算で引数として使用する前に、この値が符号なしの値に変換されると、未定義の動作が発生しました。現在は、関数が-1を返すと、これはエラーとして処理され、値はそれ以上使用されません。(Bug #31326120)
● 特定の場合の符号付きの値の否定は、未定義の動作につながりました。この発生を防ぐために、否定される値は符号なしとして扱われるようになりました。(Bug #31325602)
● WEIGHT_STRING()関数は、整数の引数に対して常に正しい結果を返すとは限りませんでした。(Bug #31321257)
参照：この問題は、Bug #30776132のリグレッションです。
● CONCAT('')またはCONCAT_WS('')を変数に割り当てると、変数は空の文字列ではなくNULLに設定されます。(Bug #31320716、Bug #99485)
● 特定の状況下で権限の制限が無視される問題を修正しました。(Bug #31306814、Bug #31315692)
● 行をロックする特定のSELECTステートメント権限が適切にチェックされず、他のユーザーを誤ってブロックする可能性がありました。(Bug #31293065)
● ファイルソートを実行すると、ソートされているサブセレクトがnullになり得ない場合でも、内部関数は失敗するとNULLを返すことがありました。(Bug #31281602)
● バイナリログのステートメントの書き換えは、Windowsでは効果がありませんでした。(Bug #31260698)
参照：この問題は、Bug #30654405のリグレッションです。
● メモリ内での匿名ユーザーの表現に一貫性がないと、権限付与操作の実行中に問題が発生する可能性がありました。(Bug #31246179)
● 管理接続インターフェースが有効な場合、競合状態により、メイン接続インターフェースでUnixソケットファイル接続を受け入れる問題が発生する可能性がありました。(Bug #31241872)
● WITH ADMIN OPTIONを使用してロールが付与された場合、権限受領者はロールをアクティブ化した後にのみロールを管理できました。(Bug #31237368)
● default_rolesまたはrole_edgesシステムテーブル内の無効な行は、サーバーの誤動作を引き起こす可能性がありました。(Bug #31217385)
● 実行時にコンポーネントの初期化解除に失敗すると、シャットダウン時にエラーログにメッセージが繰り返し書き込まれる可能性がありました。(Bug #31217037)
● 匿名ユーザーへのロール付与の禁止は、完全には実行されませんでした。(Bug #31215017)
● 権限昇格の問題が修正されました。(Bug #31210226)
● keyring_hashicorpキーリングプラグインは、その設定パラメーターの値に対して十分な有効性チェックを実行しませんでした。(Bug #31205363)
● keyring_hashicorpキーリングプラグインは、（binlog_encryptionシステム変数を設定することによって）バイナリログの暗号化を有効にすることができませんでした。(Bug #31204841)
● keyring_hashicorpキーリングプラグインは、audit_logプラグインによって暗号化パスワードを設定できませんでした。(Bug #31197670)
● ORDER BY句を指定したREGEXP_SUBSTR()を使用する一部のクエリは、サーバーで正しく処理されませんでした。(Bug #31184858)
● ポインタ演算がnullptrに適用された一部のインスタンスが修正されました。(Bug #31172750)
● 使用可能なファイル記述子がなくなった場合、mysql_real_connect()がクライアントを終了させました。(Bug #31151052)
● killallコマンドを使用してmysqldシャットダウンを開始すると、シャットダウンの開始を示すメッセージがログに記録されませんでした。これは修正されました。(Bug #31121907)
● 無効なホストでmysql_real_connect_nonblocking()を呼び出すと、mysql_close()の呼び出し時にクライアントが終了する可能性がありました。(Bug #31104389、Bug #99112)
● Debianパッケージについて、インストールの失敗の原因となる可能性があるPython 2の依存関係が削除されました。(Bug #31099324)
● lf_hash_insert()の潜在的なメモリリークが修正されました。(Bug #31090258、Bug #99078)
● LDAP SASL認証プラグイン内で、sasl_client_done()を複数回呼び出すと、場合によっては未定義の動作が発生する可能性がありました。(Bug #31088206)
● スレッドプールプラグインが有効な場合、高い並行処理状態によりクライアントコンテキストが失われ、サーバーが終了する可能性があります。(Bug #31085322)
● mysql_use_result()を使用して処理された結果セットについて、mysql_fetch_row_nonblocking()は行数を増加させなかったため、全ての行がフェッチされた後、mysql_num_rows()は誤った行数を返しました。(Bug #31082201、Bug #99073)
● 実際には評価されなかった不要なEXISTS()の最適化を削除しました。(Bug #31069510)
● --skip-grant-tablesオプションを使用して起動したサーバーについて、partial_revokesシステム変数を有効にすると、サーバーが終了しました。(Bug #31066069、Bug #31202963)
● 外部参照を含む再帰的共通テーブル式を使用したクエリは、誤った結果を返す可能性がありました。(Bug #31066001、Bug #99025)
● 最小文字長が1バイトを超えるマルチバイト文字セットの場合、パーサーが失敗する可能性がありました。(Bug #31063981)
● 場合によっては、LEAST()関数がnull可能ではない入力に対してNULLを返す可能性がありました。(Bug #31054254)
参照：この問題は、Bug #25123839のリグレッションです。
● MYSQL_OPT_CONNECT_TIMEOUTオプションが設定されている場合、mysql_real_connect_nonblocking()はブロックされます。(Bug #31049390、Bug #98980)
● null行を返すためのmysql_fetch_row_nonblocking() C API関数の最後の呼び出しは、本来あるべきでない時にエラーを設定していました。(Bug #31048553、Bug #98947)
● Windowsでは、デフォルトの接続タイプは名前付きパイプを使用します。TCP/SSL接続用のノンブロッキングC APIは、これを考慮せず、クライアントを終了させました。これは、現在は、問題を示すエラーメッセージを生成します。(Bug #31047717)
● ユーザーが存在しないために認証に失敗したXプラグイン接続は、グローバルシステム変数audit_log_filter_idを変更しました。(Bug #31025461)
● LOAD DATAは、入力ファイルの行を解析する時に非表示の生成された列を無視しませんでした。(Bug #31024266、Bug #98925)
● CREATE TABLE ... SELECTは、関数インデックスを含む場合、失敗しました。(Bug #31017765、Bug #98896)
● Xプロトコル接続の場合、グローバルセッションミューテックスのチェックが改善され、スレッド数の増加に伴うパフォーマンスのわずかな低下が解消されました。(Bug #31000043)
● 特定の場合に、複数のサブクエリを含むクエリを実行すると、サーバーが予期せずシャットダウンすることがありました。(Bug #30975826)
● FLUSH TABLES WITH READ LOCKが有効な場合、SHOW CREATE TRIGGERが失敗しました。(Bug #30964944)
● INFORMATION_SCHEMAビューの基礎となる特定のデータディクショナリテーブルで過度のアクセスチェックが実行されたために、SHOW COLUMNSのパフォーマンスが低下しました。これらのチェックは、パフォーマンスを向上させるために削減されました。
さらに、INFORMATION_SCHEMAクエリとして実装されたいくつかのSHOWステートメントは、optimizer_switchシステム変数のderived_mergeフラグを有効にすることでメリットを得られることがわかりました。そのようなクエリは、現在、フラグセッション値に関係なく、パフォーマンスを向上させるためにそのフラグを一時的に内部で有効にします。影響を受けるクエリは次のとおりです。
SHOW SCHEMAS
SHOW TABLES
SHOW TABLE STATUS
SHOW COLUMNS
SHOW KEYS
SHOW EVENTS
SHOW TRIGGERS
SHOW PROCEDURE STATUS
SHOW FUNCTION STATUS
SHOW CHARACTER SET
SHOW COLLATION
(Bug #30962261、Bug #98750、Bug #30921214)
● 他の点では同じ2つのクエリが別々に実行されると、大文字と小文字を区別する照合を使用する時は1行を、大文字と小文字を区別しない照合を使用する時は2行を返しました。同じ2つの述語がANDを使用して1つのクエリで組み合わされると、1つの行だけが返されるはずだった時に2つの行が返されました。(Bug #30961924)
● 表示幅が255を超えるSET行に対するALTER TABLEは、可能である場合でも、実行されませんでした。(Bug #30943642、Bug #98523)
● サーバーは、値をdoubleとしてULLONG_MAX（doubleとして表現できない）と比較することによって、ヨタバイト単位の数値が大き過ぎて印刷できないかどうかをチェックしました。これにより、ULLONG_MAXヨタバイトのすぐ上のdouble値が0Yとして印刷され、誤った変換がClang 10によって報告されました。(Bug #30927590)
● CREATE RESOURCE GROUPのようなリソースグループSQLステートメントは、Xプロトコルを使用する接続では機能しませんでした。(Bug #30900411)
● SHOW GRANTSは、関数権限をプロシージャ権限として表示する場合がありました。(Bug #30896461、Bug #98570)
● 複数のクライアントが同時に接続すると、audit_logプラグインが接続イベントを誤って処理しました。(Bug #30893593)
● LOCK_ORDERツールは、空の依存関係グラフの構文エラーを報告しました。現在、空のグラフは許可されています。
LOCK_ORDERツールは、スレッドリストのメンテナンスを誤って処理したため、予期しない動作を示す可能性がありました。(Bug #30889192)
● MySQL 5.7からアップグレードすると、REPLICATION_APPLIER権限がルートに付与されませんでした。(Bug #30783149)
● gen_range()ユーザー定義関数はその引数を誤って処理し、サーバーを終了させる可能性がありました。(Bug #30763294)
● UPDATE処理中に、内部のインメモリテーブルをInnoDBに変換すると、キー長エラーが発生する可能性がありました。(Bug #30674616)
● プロシージャまたは関数レベルで（常にグローバルである）動的な権限を付与しようとすると、エラーが生成されませんでした。(Bug #30628160)
● テーブル値コンストラクターはLIMIT句を無視しました。この句は、現在、考慮されます。例：VALUES ROW(1), ROW(2), ROW(3) LIMIT 2 outputs 1 and 2。(Bug #30602659)
● *（単一のアスタリスク文字）という名前の列を定義することは可能ですが、SELECT `*`がSELECT *と同じように扱われたため、クエリでこの列のみを選択することはできませんでした。つまり、アスタリスク文字は、バッククォートで囲まれている場合でも、全てのテーブル列のリストに拡大されました。(Bug #30528450)
● FROM_DAYS()関数は、範囲外の結果を生成する可能性がありました（the year > 9999を使用）。(Bug #30455845、Bug #97340)
● デバッグビルドの場合、mysql.funcテーブルをMyISAMに変更すると（どのような場合でも推奨される操作ではありません）、サーバーが終了しました。現在、この操作は禁止されています。(Bug #30248138、Bug #96692)
● INFORMATION_SCHEMA KEY_COLUMN_USAGEビューとTABLE_CONSTRAINTSビューに対するクエリは、UNIONがその定義で使用されているために、遅くなる可能性がありました。これらは、オプティマイザがインデックスをより適切に使用できるように、UNIONをLATERALテーブルに移動するように書き直されました。(Bug #30216864、Bug #30766181、Bug #98238)
● LIMIT句により、オプティマイザは、0の行がテーブルから読み取られる必要があると誤って推定する場合がありました。(Bug #30204811)
参照：この問題は、Bug #29487181のリグレッションです。
● 内部のパケット長関数が間違った整数型の値を返しました。(Bug #30139031)
● mysqldumpによるINSERTステートメントの長さの計算では、VARBINARY文字列に使用される_binary文字セットイントロデューサは考慮されませんでした。(Bug #29998457、Bug #96053)
● 接頭辞キーで定義されたパーティションテーブルのアップグレード中にエラーログに出力されるメッセージでは、十分な詳細が提供されませんでした。スキーマ、テーブル、列、接頭辞の長さを示す詳細な警告が出力されるようになりました。(Bug #29942014)
参照：Bug #31100205。
● mysql_store_result()は無効なデータパケットの検出に失敗する場合がありました。(Bug #29921423)
● 外部キーリレーションでの子テーブルの作成によりエンジンが置換されると、アサーションが発生しました。(Bug #29899151、Bug #95743)
● mysqltestおよびmysql-test-run.plは、--sleepコマンドラインオプションをサポートしなくなりました。mysqltestは、real_sleepコマンドをサポートしなくなりました。(Bug #29770237)
● サーバーは、許可された最大長（255文字）より長い名前のホストへの接続を許可しました。(Bug #29704941)
● 最初のテーブルのキーを更新するマルチテーブルUPDATEで、一時テーブル戦略が使用された場合、重複したエントリが一時テーブルに書き込まれ、その後Can't find recordというエラーが発生する可能性がありました。(Bug #28716103)
● サーバーは、クエリを最適化する時に、GROUP BYを含むサブクエリを誤って削除することがありました。このサブクエリが外部選択によって使用された場合であってもです。これは、サブクエリが集約関数も使用した時に発生する可能性がありました。(Bug #28240054)
● NAME_CONST()関数の強制性が誤って評価されました。(Bug #26319675)
● ストレージエンジンから行を読み取る時、“no more records”（レコードがありません）以外のエラーは無視され、後で問題が発生する可能性がありました。(Bug #20162055)
● マルチテーブル更新で一時テーブルを使用した場合、これはEXPLAIN FORMAT=TREEの出力には表示されませんでした。このような使用は、これが行われたUPDATEステートメントのパフォーマンスに影響を与える可能性がありました。(Bug #17978975)
● SELECT DISTINCTを実行する場合など、重複を削除するためにファイルソートを実行する場合、ORDER BYを満たすために後で別のソートを実行する必要がある可能性があります。このようなORDER BYが、結合全体ではなく、結合の最初のテーブルにプッシュダウンされた場合、この最後のソートは実際には実行されませんでした。(Bug #99687、Bug #31397840)
● MySQL 8.0.20で行われたリファクタリング作業により、null不可の列のGROUP BYに関する単一行バッファリングが正しく機能せず、そのような列が外部結合の内部テーブルである可能性があることは考慮されていませんでした。したがって、コピーされる必要のあるNULLフラグがありました。一時テーブルなしのGROUP BYでは、これによりNULLフラグが前の行ではなく次の出力行から取得され、返されたデータに一貫性がなくなりました。(Bug #99398、Bug #31252625)
参照：この問題は、Bug #30460528のリグレッションです。
● DECIMALまたはFLOAT型の定数が左側のオペランドであり、整数の列値が右側のオペランドである場合の定数折りたたみコードの論理エラーは、誤った結果をもたらしました。(Bug #99145、Bug #31110614)
● 述語が0と-0を比較したクエリで、これらの少なくとも1つが浮動小数点値であった場合、誤った結果が返されました。(Bug #99122、Bug #31102789)
● SELECT DISTINCT( HEX( WEIGHT_STRING(varchar_column) ) )は、切り捨てられた結果を返しました。(Bug #98592、Bug #30898753)
● MAX()、MIN()、またはその両方を使用し、GROUP BY句を組み合わせたクエリでのエラー処理の問題は、このようなクエリが、エラーが原因で即座に終了する必要がある場合でも、可能な全ての反復が完了するまで実行し続けたことを意味しました。(Bug #98242、Bug #30769515)
● スライスを使用しないロールアップを再実装しました。これにより、次の既知の問題が修正されます。
・GROUP BY ... WITH ROLLUPの繰り返し列が誤った結果をもたらしました。つまり、GROUP BY a, bの形式のGROUP BY、WITH ROLLUPは、結果の一部の列名に対してNULLを誤って生成しました。
・結果を出力するために一時テーブルを必要としないGROUP BY ... WITH ROLLUPも、出力で少なくとも1つの予期される列名の代わりに誤ったNULLを生成しました。
(Bug #96768、Bug #30967158、Bug #26227613、Bug #30969045、Bug #29134467)
● LEAST（）、GREATEST（）、その他の関数、およびUNIONの型伝播コードをリファクタリングした後、ENUMのようなデータ型の結果型の調整により、計算された整数データ型も、符号付きと符号なしの両方の値に対応できない型に置き換えられました。(Bug #95148、Bug #29698617)
参照：この問題は、Bug #83895、Bug #25123839のリグレッションです。
全ての変更点やバグ修正については、以下のページをご覧ください。
MySQL 8.0.21 リリースノート（MySQLウェブサイト）：
https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-21.html
MySQL Editions
MySQLのサブスクリプションは、24時間365日体制でお客様をサポートいたします。さらに MySQL Enterprise Edition では、データベース管理者支援ツール MySQL Enterprise Monitor やバックアップツール MySQL Enterprise Backup をご利用いただけます。