主な変更点
■ 監査ログ関連
・暗号化されたMySQL Enterprise Auditのログファイルの暗号化および復号化操作は、 MySQLキーリングに保存されているパスワードを使用します。 以前は、1つのパスワードしか保存されていませんでした。新しいパスワードを生成すると 古いパスワードにアクセスできなくなり、MySQL Enterprise Auditは古いパスワードで 暗号化されたログファイルを読み取ることができなくなりました。MySQL Enterprise Auditは、 現在、キーリングのパスワード履歴を保持するために古いパスワードをアーカイブし、 ファイルを読み取るために必要なパスワードのIDをそれぞれの暗号化されたログファイルの 名前に含めます。キーリングのアーカイブされた古いパスワードの有効期限とクリーンアップを 有効にするために、新しいaudit_log_password_history_keep_daysシステム変数が利用可能です。
■ C API関連
・C APIの変更点： * HOSTNAME_LENGTHは、60から255に変更され、include/mysql_com.hからinclude/my_hostname.hに 移動されました。 * USER_HOST_BUFF_SIZEは、include/mysql_com.hからsql/auth/auth_common.hに移動されました。 (Bug #29590300)
■ キャラクターセットサポート
・utf8mb4キャラクターセットに、新しいバイナリ照合順序 utf8mb4_0900_binが追加されました。 これは、以下の点が既存のutf8mb4_binバイナリ照合順序と異なります。 * 重みを照合するために、utf8mb4_binはコードポイントを使用し、先頭に0バイトが追加されている 可能性があります。一方、utf8mb4_0900_binはutf8mb4エンコーディングバイトを使用します。 ソート順は両方の照合順序で同じですが、utf8mb4_0900_binのソートははるかに高速です。 * utf8mb4_binのpad属性はPAD SPACEですが、utf8mb4_0900_binの場合はNO PADです。その結果、 utf8mb4_0900_binを含む演算は末尾のスペースを追加せず、末尾のスペースを持つ文字列を含む 比較は2つの照合順序で異なる可能性があります。
■ コンポーネント関連
・サーバーコンポーネントが現在のスレッドへのハンドルを取得できるようにするために、 新しいmysql_current_thread_readerコンポーネントサービスが利用可能です。例えば、 このサービスを使用すると、コンポーネントはそのスレッドハンドルを他のサービスに 渡すことによって現在のセッションのプロパティにアクセスできます。 このサービスの詳細は、https：//dev.mysql.com/doc/index-other.htmlにある MySQL Server DoxygenのドキュメントのComponent Subsystemセクションを参照してください。
■ 設定関連
・mysys_sslディレクトリー内のソースファイルがmysysディレクトリーに移動され、 mysys_sslライブラリがビルドされなくなりました。（Bug #29488066） ・MySQLの設定には、現在、最低でもバージョン3.5.1のCMakeが必要です。（Bug #29337090） ・MySQL全体のホスト名の最大許容長が、以前の上限である60文字から255文字のASCII文字に 増やされました。これは、例えば、データディクショナリー、mysqlシステムスキーマ、 パフォーマンススキーマ、INFORMATION_SCHEMA、およびsysスキーマ内のホスト名関連の カラムに適用されます; CHANGE MASTER TOステートメントのMASTER_HOST値; SHOW PROCESSLISTステートメントの出力のHostカラム; （例えば、アカウント管理ステートメントやDEFINER属性で使用されるような）アカウント名に 含まれるホスト名; ホスト名関連のコマンドオプションやシステム変数。 注意事項： * 許可されたホスト名の長さの増加は、ホスト名のカラムにインデックスがあるテーブルに 影響を与える可能性があります。例えば、ホスト名にインデックスを設定する mysqlシステムスキーマのテーブルは、より長いインデックス値に対応するために DYNAMICの明示的なROW_FORMAT属性を持つようになりました。 * 一部のファイル名値の設定は、サーバーのホスト名に基づいて構成されている場合があります。 許可される値は、基礎となるオペレーティングシステムによって制限されます。 オペレーティングシステムは、255文字のホスト名を含むために十分な長さのファイル名を 許可しない可能性があります。これは、general_log_file、log_error、pid_file、relay_log、 slow_query_log_fileの各システム変数と、それに対応するオプションに影響します。 ホスト名に基づく値がOSに対して長すぎる場合は、明示的に短い値を指定する必要があります。 * サーバーは現在255文字のホスト名をサポートしていますが、 --ssl-mode=VERIFY_IDENTITYオプションを使用して確立されたサーバーへの接続は、 OpenSSLでサポートされているホスト名の最大長によって制限されます。ホスト名の一致は、 SSL証明書の2つのフィールドに関係します。これらのフィールドの最大長は以下のとおりです。 Common Name：最大長64、Subject Alternative Name：RFC#1034による最大長。 ホスト名が最大60文字であると予想されるアプリケーションは、この変更を考慮して 調整されるべきです。（Bug #13548245、Bug #63814、Bug #27925782、Bug #90601、 Bug #27955121、Bug #29584642、Bug #29602081、Bug #94907）
■ デバッグ関連
・MySQLサーバーは、ミューテックスなどの内部ロックプリミティブを多数使用する マルチスレッドアプリケーションです。ロック獲得デッドロックの検出とランタイム実行が それらから自由であるという強制を可能にするために、MySQLは現在LOCK_ORDERツールを サポートします。これにより、ロック順序依存関係グラフがサーバー設計の一部として定義される ことを可能にしたり、サーバーの実行時チェックはロックの獲得が非循環的であることや 実行パスがグラフに適合していることを確認できます。LOCK_ORDERのサポートには以下が 含まれます。 * サーバーのロック順序依存関係グラフを定義するlock_order_dependencies.txtファイル。 * MySQLがLOCK_ORDERツールを含んでビルドされるかどうかを設定するWITH_LOCK_ORDER CMake オプション。 * サーバー実行中のLOCK_ORDERツール操作を設定する一連のシステム変数。 * テストケースの実行中にLOCK_ORDERツールを有効にするかどうかを制御するmysql-test-run.plの --lock-orderオプション。 LOCK_ORDERツールを使用するためには、有効にされたツールを含むソースからMySQLを ビルドしなければなりません。LOCK_ORDERツールはサーバーをデバッグするためのものであり、 本番使用のためのものではありません。
■ 廃止予定と削除
・FLOAT型、DOUBLE型（およびシノニム）のカラムの桁数を指定するFLOAT(M,D)とDOUBLE(M,D)構文は、 非標準のMySQL拡張機能です。この構文は推奨されておらず、そのサポートは将来のMySQLバージョンで 削除される予定です。（Bug #25328973、Bug #84363） ・文字列データ型の場合、BINARY属性はカラムのキャラクターセット（または、カラムの キャラクターセットが指定されていない場合はテーブルのデフォルトキャラクターセット）の バイナリ（_bin）照合順序を指定することを簡略化した非標準のMySQL拡張機能です。 MySQL 8.0では、utf8mb4キャラクターセットには複数の_bin照合順序があるため、 このBINARYの非標準的な使用はあいまいです。したがって、BINARY属性は推奨されておらず、 そのサポートは将来のMySQLバージョンで削除される予定です。アプリケーションは、 代わりに明示的な_bin照合順序を使用するように調整される必要があります。 データ型またはキャラクターセットを指定するためのBINARYの使用はそのまま変わりません。 ・標準SQLのAND、OR、NOT演算子の同義語である、非標準のC-スタイルの&&、||、!の演算子は、 推奨されておらず、それらのサポートは将来のMySQLバージョンで削除される予定です。 非標準の演算子を使用するアプリケーションは、標準演算子を使用するように調整される 必要があります。 注意 ||の使用は、PIPES_AS_CONCAT SQLモードが有効でない限り、推奨されません。その場合、 ||はSQL標準の文字列連結演算子を意味します。 ・ZEROFILL属性は、整数データ型の表示幅属性であるので、数値データ型では推奨されません。 ZEROFILLと整数データ型の表示幅のサポートは、将来のMySQLバージョンでは削除される予定です。 これらの属性の効果をもたらず代替方法を使用することを検討してください。 例えば、アプリケーションはLPAD()関数を使用して数字を目的の幅までゼロ埋めしたり、 フォーマットされた数字をCHARカラムに格納することができます。 ・UNSIGNED属性は、FLOAT、DOUBLE、DECIMAL型（およびシノニム）のカラムでは推奨されておらず、 将来のMySQLバージョンで削除される予定です。そのようなカラムに関しては、代わりに 単純なCHECK制約を使用することを検討してください。 ・AUTO_INCREMENTのサポートは、FLOAT型とDOUBLE型（およびシノニム）のカラムでは推奨されて おらず、将来のMySQLバージョンで削除される予定です。このようなカラムからAUTO_INCREMENT属性を 削除することを検討するか、それらを整数型に変換してください。 ・SQL_CALC_FOUND_ROWSクエリ修飾子とそれに付随するFOUND_ROWS()関数は現在推奨されておらず、 将来のMySQLバージョンで削除される予定です。代わりに、LIMITを使用したクエリを実行し、 次にLIMITを使用しないCOUNT(*)を使用する2番目のクエリを実行して、追加の行があるかどうかを 判断します。例えば、これらのクエリの代わりに、 SELECT SQL_CALC_FOUND_ROWS * FROM tbl_name WHERE id > 100 LIMIT 10; SELECT FOUND_ROWS(); 代わりにこれらのクエリを使用してください。 SELECT * FROM tbl_name WHERE id > 100 LIMIT 10; SELECT COUNT(*) WHERE id > 100; COUNT(*)は特定の最適化の対象となります。SQL_CALC_FOUND_ROWSはいくつかの最適化を無効にします。
■ インストール関連
・サーバー起動時の自動アップグレードは、完了までに時間がかかることがあります。 systemd環境でのステータス通知を改善するために、サーバーはアップグレードの開始時と 終了時にシステム通知ソケットにメッセージを送信するようになりました。 （ステータスはサーバーのmysqldステータスで監視できます。）（Bug #29493201）
■ キーリング関連
・keyring_awsプラグインが最新のAWS SDKを使用するように更新され、OpenSSL 1.1で動作するように なりました。
■ パッケージング関連
・mysql-community-server Linuxパッケージのダウンロードサイズとディスク容量を減らすために、 デバッグバイナリとプラグインは、これらのプラットフォーム用の個別のパッケージに移動されました。 * EL8、Fedora：デバッグバイナリと関連プラグインを含むmysql-community-serverパッケージは、 デバッグバイナリもプラグインも含まないmysql-community-serverパッケージと、 デバッグバイナリとプラグインを含むmysql-community-server-debugパッケージに分けられました。 * Debian：デバッグバイナリと関連プラグインを含むmysql-community-serverパッケージは、 デバッグバイナリもプラグインも含まないmysql-community-serverパッケージ、 デバッグバイナリを含むmysql-community-server-debugパッケージ、 デバッグプラグインを含むmysql-community-test-debugパッケージに分けられました。 すべての場合で、debugパッケージは対応するmysql-community-serverパッケージに依存しています。 （Bug #29769061、Bug #28647754、Bug #92415、Bug #29702765、Bug #95169、Bug #29681301）
■ パフォーマンススキーマ関連
・コンパイル時のパフォーマンススキーマのバージョンチェックは、サーバーバージョンとの非互換性を 防ぐために改善されました。（Bug #29550156） ・以前は、RWLOCKに関するパフォーマンススキーマのインストルメンテーションは、優先読み取り/ 書き込みロックをrwlockと命名し（したがって、単純なロックと優先ロックを区別できなかった）、 実行されたロック解除操作の種類に関する情報を収集しませんでした。 優先読み取り/書き込みロックはprlockと命名されるようになったため、それらに対するイベントは wait/synch/prlockで始まります。また、ロック解除操作に関する情報も提供されます。 （Bug #29270712）
■ プラグイン関連
・--early-plugin-loadオプションを使用してサーバーの起動シーケンスの"早い段階"でロードされる場合 （つまりInnoDBが初期化される前に）、すべてのプラグインが正常に動作できるわけではありません。 しかし、InnoDBは暗号化されたテーブルを操作するためにキーリングバックエンドプラグインを 必要とします。プラグインが早い段階でロードされることが可能かどうかをサーバーに示すことを 可能にするために、新しいPLUGIN_OPT_ALLOW_EARLYフラグがプラグイン記述子で使用可能です。 MySQLディストリビューションに含まれるキーリングプラグインは、InnoDBが必要とするため、 PLUGIN_OPT_ALLOW_EARLYフラグを有効にしましたが、そのフラグはキーリングプラグインに 限定されません。サーバー起動シーケンスの早い段階で正常に初期化できる他のプラグインに対して 設定される可能性があります。 このフラグは、サーバー起動時に--plugin-loadまたは--plugin-load-addオプションを使用して、 または実行時にINSTALL PLUGINステートメントを使用して、プラグインがロードされ得るかどうかには 影響しません。 8.0.17より前のMySQLディストリビューションを使用してコンパイルされたすべてのプラグインには、 このフラグは設定されていません。これらを8.0.17より前のサーバーにロードする場合は 問題ありませんが、8.0.17より前のMySQLディストリビューションを使用してコンパイルされた プラグインバイナリを8.0.17以降のサーバーにロードするために--early-plugin-loadを使用しようと すると失敗します。プラグインはMySQL 8.0.17以降に対して再コンパイルされる必要があります。 （Bug #29040456、Bug #93550）
■ Xプラグイン関連
・MySQL 8.0.16でのリグレッションが原因で、createIndex()メソッドは倍精度値を指定するための DOUBLE(M,D)構文をサポートしませんでした。（Bug #29748841） ・オクテットとしてエンコードされた引数を含むメッセージのXプロトコルの処理は、文字列配列などの 非スカラーのデータをサポートするように修正されました。（Bug #29721046） ・SSL接続でホスト名の本人確認が有効になっている場合（--ssl-mode=VERIFY_IDENTITY）、 Xプロトコルはサーバーの証明機関（CA）の証明書の中のサブジェクトの別名（SAN）との一致を 確認しませんでした。これにより、証明書のCommon Name値としてではなくSANとして指定された 有効なホスト名が使用されたため、接続リクエストが不必要に拒否される可能性がありました。 （Bug #29691694） ・プリペアドステートメントがXプラグインで使用された場合、修正操作または検索操作で INまたはNOT INを使用すると無効なJSONが生成され、エラーとなりました。（Bug #29259501） ・Windowsでは、Xプラグインは不要なメッセージまたは情報が不十分なメッセージのいくつかを 記録しました。メッセージは必要に応じて削除または改善されています。（Bug #27839153） ・XプラグインのSQL関数リストは古く、新しい関数を追加し、使用できなくなった関数を削除して 更新されました。（Bug #26574971）
■ 追加・変更された機能
・InnoDB; JSON：InnoDBは現在、JSON配列の多値インデックスをサポートしています。
多値インデックスは、複数のインデックスレコードが同じデータレコードを指すことができる
インデックスです。これは、{user:"Bob",zipcode:[94477,94536]}のようなJSONドキュメントを
インデックス付けするのに役立ちます。すべての郵便番号を検索したい場合は、ドキュメントの
各郵便番号ごとに2つのインデックスレコードが必要です。以下のような
CREATE INDEXステートメントを使用して、郵便番号配列にそのようなインデックスを作成できます。
CREATE INDEX zips ON t1( (CAST(data->'$.zipcode' AS UNSIGNED ARRAY)) )
事実上、これはCAST()関数を使用した関数インデックスです。これは、ARRAYキーワードを使用して
拡張され、JSON配列をSQLデータ型配列にキャストできるようにしました。パス式は
有効なJSONパスでなければならず、有効であるためにJSONドキュメント内の配列を指している必要が
あります。BINARYを除いて、CAST()によってサポートされるすべての型指定子を使用できます。
このようなCAST()関数の使用は、InnoDBでのみサポートされており、JSON配列に多値インデックスを
作成する場合に限られます。
この作業の一部として、MySQLはここに記述されているとおり、JSONドキュメントを操作するための
新しいMEMBER OF()演算子と同様に新しい関数JSON_OVERLAPS()を追加します。
* JSON_OVERLAPS()は、2つのJSONドキュメントを比較します。それらに共通のキーと値のペア
または配列要素が含まれている場合、この関数はTRUE(1)を返します。それ以外の場合は
FALSE(0)を返します。両方の値がスカラーの場合、この関数は等価性について単純なテストを
実行します。一方の引数がJSON配列で、もう一方がスカラーの場合、スカラーは配列要素として
扱われます。したがって、JSON_OVERLAPS()はJSON_CONTAINS()の一部として機能します。
* MEMBER OF()は、最初のオペランド（スカラーまたはJSONドキュメント）が
2番目のオペランドとして渡されたJSON配列のメンバーであるかどうかを確認し、そうであれば
TRUE(1)を、そうでなければFALSE(0)を返します。オペランドの型変換は行われません。
MySQLオプティマイザは、適切なクエリ、つまりJSONカラム内の配列に対してJSON_CONTAINS()、
JSON_OVERLAPS()、またはMEMBER OF()のいずれかをWHERE句で使用するクエリに対して、自動的に
多値インデックスを使用します。そのようなインデックスが実際に使用されているかどうかは、
与えられたクエリに対するEXPLAINの出力をチェックすることによって確認できます。
・Microsoft Windows：新しい警告メッセージは、Windows上でMySQLの名前付きパイプを使用して
行われた接続がコネクタが名前付きパイプで要求できる権限を制限していることをDBAに知らせます。
以前は、named_pipe_full_access_groupシステム変数は、デフォルトで組み込みのWindowsの
Everyoneグループ（SID S-1-1-0）にマップされる値に設定されていました。しかし、
このグループは理想的でなく、MySQLの名前付きパイプに対するより少ない許可を要求することが
できないコネクタのメンバーシップを制限するグループに置き換えられるべきです。
named_pipe_full_access_groupに割り当てられた文字列値が '*everyone*'（または
Windowsシステム言語の同等のもの）であり、名前付きパイプが有効な場合、
新しい警告が起動時にエラーログに書き込まれます。さらに、システム変数が実行時に
Everyoneグループにリセットされると、警告がエラーログに書き込まれ、クライアントに
通知されます。
・X DevAPI：Collectionオブジェクトについては、以下のメソッドは推奨されておらず、
将来のリリースで削除される予定です。
* Collection.find().where()
* Collection.modify().where()
* Collection.remove().where()
.where()メソッドに依存するすべてのCollectionコードは更新される必要があり、
.where()メソッド内の式は適切な.find()、.remove()、および.modify()メソッドで
直接指定される必要があります。
・JSON：MySQLは、現在、2つの関数JSON_SCHEMA_VALID()とJSON_SCHEMA_VALIDATION_REPORT()を
使用したJSONスキーマ検証をサポートしています。そのいずれも、JSONスキーマ仕様のDraft 4に
準拠しているJSONスキーマに対してJSONドキュメントを検証します。JSON_SCHEMA_VALID()は、
ドキュメントがスキーマに対して検証される場合はtrueを返し、検証されない場合はfalseを
返します。JSON_SCHEMA_VALIDATION_REPORT()は、検証結果に関する詳細情報を含む
JSONドキュメントを返します。
これらの関数の両方について、以下のことが当てはまります。
* 必須属性がサポートされています。
* 正規表現がサポートされています（無効な表現は黙って無視されます）。
* スキーマ内の外部リソースと$refキーワードはサポートされていません。
・time_zoneセッション変数は、現在、SET_VARオプティマイザヒントを使用してヒント可能です。
（Bug #29776464）
・libmysqlclient.so Cクライアントライブラリのマイナーバージョンが、新しいシンボルが
追加されたことを知らせるために、1に(21.0から21.1に)なりました。これは、
MySQL 8.0.16リリースの見落としを修正するために行われました。互換性の懸念に対処するために、
すべてのシンボルのバージョンは変更されていません。これは、ライブラリのファイル名が
libmysqlclient.so.21.1.17であるのに対し、ライブラリ内のすべてのシンボルは21_0として
タグ付けされていること（8.0.16リリースから変更なし）を意味します。
（Bug #29584073、Bug #29642146）
・mysqlクライアントプログラムは、現在、os_userとos_sudouserの接続属性が使用可能であれば、
それらを送信して、プログラムを実行しているオペレーティングシステムユーザーの名前と
SUDO_USER環境変数の値を示します。（Bug #29210935、Bug #93916）
・SHOW CREATE USERからの出力のIDENTIFIED WITH句に表示されるパスワードのハッシュ値には、
端末のディスプレイや他の環境に悪影響を与える印刷できない文字が含まれている可能性が
あります。新しいprint_identified_with_as_hexシステム変数を有効にすると、
SHOW CREATE USERはそのようなハッシュ値を通常の文字列リテラルとしてではなく
16進数文字列として表示します。印刷できない文字を含まないハッシュ値は、この変数が
有効になっていても、通常の文字列リテラルとして表示されます。この変更との互換性のために、
CREATE USERおよびALTER USERは、現在、通常の文字列リテラルまたは16進数文字列の
いずれかとして指定されたハッシュ値を受け入れます。（Bug #28053446、Bug #90947）
・MySQL 8.0では、MySQLサーバーが初期化される時にのみ、lower_case_table_names変数を
設定できます。APTを使用して実行されたDebianおよびUbuntuへのMySQLサーバーの
インストールはMySQLサーバーを初期化するため、lower_case_table_namesを有効にする機会が
ありませんでした。この問題を回避するために、APTを使用してMySQLをインストールする前に
debconf-set-selectionユーティリティを使用してlower_case_table_namesを有効にする
（set lower_case_table_names=1）ことができます。
APTを使用してMySQLをインストールする前にlower_case_table_namesを有効にするためには、
次のコマンドを実行します。
shell> sudo debconf-set-selections <<< "mysql-server mysql-server/lowercase-table-names select Enabled
（Bug #27948395、Bug #90695）
・サーバーによる起動時のSSLサーバー証明書の確認を改善し、問題がある場合はサーバーは
エラーログに警告を書き込みます。（Bug #25945005）
・SELECT ... INTO OUTFILEまたはSELECT ... INTO DUMPFILEを使用して作成されたファイルのumaskは
0666から0640に変更されました。LOAD_FILE()関数は、ファイルが世界的に読み取り可能であることを
もはや必要とせず、単にサーバーによって読み取り可能です。（Bug #24513720）
・mysqldumpオプション --set-gtid-purgedは、SET @@GLOBAL.gtid_purgedステートメントが
mysqldumpの出力に追加されるかどうかを制御します。このステートメントは、ダンプファイルが
リロードされるサーバー上のgtid_purgedの値を更新して、ソースサーバーのgtid_executed
システム変数からGTIDセットを追加します。新しい選択として、--set-gtid-purged=COMMENTEDが
利用可能になりました。この値が設定されている場合、バックアップしているサーバーでGTIDが
有効になっていると、SET @@GLOBAL.gtid_purgedがその出力に追加されます（gtid_executedが
空でない限り）。ただし、それはコメントアウトされています。これは、gtid_executedの値が
出力で使用可能であることを意味しますが、ダンプファイルのリロード時には自動的には何も
実行されません。COMMENTEDを使用すると、gtid_executedセットの使用を手動または自動化によって
制御できます。例えば、すでに異なるアクティブデータベースを持つ別のサーバーにデータを
移行している場合は、これを実行することをお勧めします。
（Bug #94332、Bug #29357665）
・MySQLは、現在、CAST()関数またはCONVERT()関数のいずれかを使用したDOUBLE、FLOAT、および
REALへの明示的キャストをサポートしています。（Bug #30524、Bug #11747058）
・InnoDBは、現在、REDOログのアーカイブをサポートしています。REDOログレコードをコピーする
バックアップユーティリティは、バックアップ操作の進行中、REDOログの生成に後れを取ることが
あり、それらのレコードが上書きされるためにREDOログレコードが失われることがあります。
REDOログのアーカイブ機能は、アーカイブファイルにREDOログレコードを順番に書き込むことによって
この問題を解決します。バックアップユーティリティは、必要に応じてアーカイブファイルから
REDOログレコードをコピーできるため、データが失われる可能性を回避できます。
・JSONデータに追加のインデックスオプションを提供するために、InnoDBは、現在、
マルチバリューインデックスをサポートしています。多値インデックスは、
値の配列を含むカラムに定義されたセカンダリインデックスです。
・MySQLは、現在、InnoDBデータをローカルまたはリモートのMySQLサーバーインスタンスから
クローニングすることを可能にするクローンプラグインを提供しています。ローカルの
クローニング操作では、MySQLインスタンスが実行しているのと同じサーバーまたはノードに
クローンデータを保存します。リモートのクローニング操作では、
ドナーMySQLサーバーインスタンスからクローニング操作が開始された受信サーバーまたは
受信ノードにクローニングされたデータをネットワーク経由で転送します。
クローンプラグインはレプリケーションをサポートしています。データのクローニングに加えて、
クローニング操作はドナーからレプリケーション座標を抽出して転送し、それらを受信側に
適用します。これにより、グループレプリケーションのメンバーおよびレプリケーションスレーブの
プロビジョニングにクローンプラグインを使用できるようになります。プロビジョニングへの
クローンプラグインの使用は、大量のトランザクションの複製よりもはるかに高速で効率的です。
グループレプリケーションのメンバーには、別のリカバリ方法としてクローンプラグインの使用を
設定することも可能です。そのため、メンバーはシードメンバーからグループデータを取得するために
最も効率的な方法を自動的に選択します。
・グループレプリケーションがグループのメンバーのバージョンに対して実装する互換性ポリシーは、
現在、メンバーのMySQLサーバーリリースのパッチのバージョンを考慮します。以前は、
メジャーバージョンのみが考慮されていました。パッチのバージョンを使用するということは、
グループレプリケーションがグループの再設定およびアップグレード手順の間にバージョンが
混在するグループに対するレプリケーションの安全性を向上させることができることを意味します。
互換性ポリシーは、初めてまたはアップグレード後にメンバーがグループに参加した時、
ドナーが状態転送のために選ばれる時、および、プライマリメンバーの選択が行われた時に
適用されます。MySQL 8.0.16以下またはMySQL 5.7を実行しているメンバーは、これらの状況では
メジャーバージョンのみを考慮に入れます。プライマリメンバーの選択については、すべての
メンバーが同じ決定に至るように、MySQL 8.0.17からのリリースを実行しているメンバーは、
より低いリリースを実行しているメンバーがグループ内にいる場合はそのメンバーに合わせて
ポリシーを調整します。
複数のMySQLサーバーのバージョンを実行しているメンバーがオンラインである
マルチプライマリモードグループでは、例えばローリングオンラインアップグレード手順の間に、
グループレプリケーションはMySQL 8.0.17からのリリースを実行しているメンバーの読み書き
および読み取り専用ステータスを自動的に管理するようになりました。メンバーがグループから
離れると、現在最も低いバージョンを実行しているメンバーは自動的に読み書きモードに
設定されます。group_replication_switch_to_multi_primary_mode() UDFを使用して、
シングルプライマリモードで実行されていたバージョン混在グループを
マルチプライマリモードで実行するように変更すると、グループレプリケーションは
MySQLサーバーのバージョンに応じて自動的にメンバーを読み書きモードまたは
読み取り専用モードに設定します。
改善された互換性ポリシーは、あるメジャーバージョンから別のバージョンへのアップグレード中の
動作が以前影響を受けたのと同じように、あるパッチバージョンから別のバージョンへの
オンラインアップグレード手順中のグループメンバーの動作に影響します。
マルチプライマリモードグループの場合、読み書きモードのメンバー数はアップグレード手順中
削減されますが、現在は、アップグレードが完了するとグループレプリケーションが自動的に
読み書きステータスを管理します。シングルプライマリモードグループの場合、プライマリを
プライマリのままにしたい場合は、それを最後にアップグレードする必要があります。
・グループレプリケーションでは、現在、分散リカバリー中に参加メンバーへの状態転送に
リモートクローニング操作を使用できます。リモートのクローニング操作では、事前に手動で
グループのデータをサーバーに転送することなく、新しいメンバーをグループに追加できます。
この機能を使用するためには、ドナーおよび参加メンバーにクローンプラグインをインストールし、
分散リカバリーのためにレプリケーションユーザーにBACKUP_ADMIN権限を付与し、
新しいgroup_replication_clone_thresholdシステム変数を適切なレベルに設定する必要があります。
グループレプリケーションは、必要なクローンプラグイン設定を自動的に設定し、
リモートクローニング操作を管理します。クローニングが完了し、参加メンバーが再起動すると、
リモートのクローニング操作の進行中にグループが適用したトランザクションは、ドナーの
バイナリログからのレプリケーションによって参加メンバーに転送され、分散リカバリーを完了します。
・トランザクション中にバイナリログトランザクションとステートメントキャッシュに保持される
データは、キャッシュを保存するメモリバッファ内で暗号化されていない形式です。データが
メモリバッファの空き容量を超えると、データはディスク上の一時ファイルに書き込まれます。
MySQL 8.0.17からは、バイナリログ暗号化がサーバー上でアクティブになっている
（binlog_encryption=ON）場合、バイナリログキャッシュに使用される一時ファイルは、
ストリーム暗号化のためにAES-CTR（AESカウンターモード）を使用して暗号化されます。
一時ファイルは揮発性であり、単一プロセスに関係しているため、メモリー内にのみ存在し
ディスクやキーリングには保存されない、ランダムに生成されたファイルパスワードと
初期化ベクトルを使用して、単層暗号化を使用して暗号化されます。各トランザクションが
コミットされると、バイナリログキャッシュがリセットされます。メモリバッファがクリアされ、
バイナリログキャッシュを保持するために使用される一時ファイルがトランケートされ、
新しいファイルパスワードと初期化ベクトルが次のトランザクションで使用するために
ランダムに生成されます。このリセットは、通常のシャットダウン後または予期しない停止後に
サーバーが再起動された時にも行われます。
・不完全なSQL述語は、WHERE valueという形式を取ります。valueはカラム名または定数式であり、
比較演算子は使用されません。クエリリゾルバ、クエリオプティマイザ、および
クエリエグゼキュータが完全な述語でのみ動作する必要があるために、MySQLは、現在、
コンテキスト化フェーズ中にこのタイプの述語をWHERE value != 0として内部的に書き換えます。
この変更の主な目に見える影響は、Boolean値の場合、EXPLAIN出力が1と0ではなくtrueとfalseを
表示するようになったことです。
・オプティマイザは、現在、NOT IN (サブクエリ)、NOT EXISTS (サブクエリ)、
IN (サブクエリ) IS NOT TRUE、または、EXISTS (サブクエリ) IS NOT TRUEを含む
WHERE条件を内部的にアンチ結合に変換し、その結果サブクエリを削除しました。
これは既存のIS NULL（存在しない）外部結合の最適化と似ています。
さらに、IN (サブクエリ) IS TRUEまたはEXISTS (サブクエリ) IS TRUEEを含むWHERE条件の場合、
または、IN条件がSELECT * FROM t1 LEFT JOIN t2 ON t2.x IN (SELECT * FROM t3)のような
LEFT JOINに属する場合に、準結合マテリアライゼーションを使用できるようになりました。
また、この作業の結果として、MySQLは、(x IS TRUE) IS FALSEの形式の条件をx IS NOT TRUEの
ように簡素化できるようになりました。これにより、元々書かれていた条件よりもより迅速に
テストされ、より簡単に最適化されます。
・大規模データセットのInnoDB並列読み取りスレッドのパフォーマンスは、読み取りスレッドの
利用の向上、並列スキャン中に発生するプリフェッチアクティビティの読み取りスレッドI/Oの
減少、およびパーティションの並列スキャンのサポートによって完全されました。
並列読み取りスレッド機能は、innodb_parallel_read_threads変数によって制御されます。
現在、最大設定は256で、これはすべてのクライアント接続のスレッドの合計数です。
スレッド制限に達すると、接続は単一スレッドの使用にフォールバックします。
・mysqlbinlogは、現在、クライアント/サーバープロトコルでの圧縮を有効にする--compress
（または-C）オプションをサポートしています。
■ 主なバグ修正
・NDB Cluster：MySQL Clusterの実行に必ずしも必要ではないソフトウェアコンポーネントの オプションを削除することによって、含まれているcompile_clusterビルドスクリプトを使用した NDB Clusterのコンパイル時間が改善されました。（Bug #29355872） ・NDB Cluster：ALTER TABLE ALGORITHM=INPLACEを使用してNDBテーブルのカラムプロパティ （COLUMN_FORMATなど）を変更しようとすると拒否されました。これは正しい動作ですが、 誤解を招くエラーメッセージが表示されました。（Bug #28929906） ・InnoDB：行数を実行中のプロセスを強制終了しようとした時に失敗しました。（Bug #29939617） ・InnoDB：MySQL 8.0.14で発生したリグレッションが原因で、MySQL 5.7またはMySQL 8.0.14より前の MySQL 8.0リリースからMySQL 8.0.16への大文字と小文字の区別があるファイルシステムの インプレースアップグレードがパーティション化されたテーブルを含みlower_case_table_names=1 であるインスタンスで失敗しました。この失敗は、パーティション化されたテーブルのファイル名に 関連する大文字と小文字の不一致の問題が原因でした。このリグレッションを発生させた修正は 元に戻され、MySQL 5.7またはMySQL 8.0.14より前のMySQL 8.0リリースからMySQL 8.0.17への アップグレードが正常に機能できるようになりました。しかし、リグレッションは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 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へのアップグレード時にこのエラーが発生した場合は、次の回避策を実行してください。 a． --upgrade=FORCEを指定してサーバーを再起動して、アップグレード操作を強制的に 進めるようにします。 b． パーティション化されたテーブルのファイル名を小文字の接尾辞で割り出します。 mysql> SELECT FILE_NAME FROM INFORMATION_SCHEMA.FILES WHERE FILE_NAME LIKE '%#p#%' OR FILE_NAME LIKE '%#sp#%'; c． 割り出された各ファイルについて、一時名を使用して関連テーブルの名前を変更し、 その後テーブルの名前を元の名前に戻します。 mysql> RENAME TABLE table_name TO temporary_table_name; mysql> RENAME TABLE temporary_table_name TO table_name; d． 小文字の接尾辞を持つパーティション化されたテーブルのファイル名がないことを 確認してください（空の結果セットが返されるはずです）。 mysql> SELECT FILE_NAME FROM INFORMATION_SCHEMA.FILES WHERE FILE_NAME LIKE '%#p#%' OR FILE_NAME LIKE '%#sp#%'; Empty set (0.00 sec) e． 名前が変更された各テーブルで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の大文字小文字を区別するファイルシステムでは サポートされていません。それを実行しようとすると、“テーブルスペースがテーブルにありません” というエラーが発生します。（Bug #29823032、Bug #29917793、Bug #95834） 参考：この問題は、Bug #26925260のリグレッションです。 ・InnoDB：ロック待機関数（lock_wait_suspend_thread()およびlock_wait_table_release_slot()） によるlock_sysミューテックスの競合が軽減されました。（Bug #29814339） ・InnoDB：セグメントによって予約されるページ数を決定するfseg_n_reserved_pa??ges_low()関数は セグメントのiノードから読み取られた結果を検証しませんでした。（Bug #29761998） ・InnoDB：トランザクションロールバックリスト（hit_list）の作成は、異なるラッチスキーマの 使用を許可するためにロック獲得の呼び出し（lock_rec_lockの呼び出し）から切り離されました。 （Bug #29753800） ・InnoDB：パフォーマンススキーマコンシューマを無効にすると、 ALTER TABLESPACE ... ENCRYPTION操作がアサートされました。（Bug #29646974、Bug #95005） ・InnoDB：MySQL 8.0では使用されていない.frmファイルへの参照を削除するように エラーメッセージが修正されました。（Bug #29639655） ・InnoDB：UNDOテーブルスペースが完全に初期化され、その暗号化フラグが設定される前に、 バックグラウンドスレッドはUNDOテーブルスペースの暗号化ステータスをチェックすることが 可能でした。 （Bug #29600309） ・InnoDB：データベース名を含むようにフォーマットされていない SDI（Serialized Dictionary Information）テーブルの名前を解析する時、 テーブル名解析関数の呼び出しはfalseを返しました。 データベース名を保持するバッファは初期化されていないままで、 Valgrindエラーが発生しました。（Bug #29550527） ・InnoDB：動的メタデータロギング用にミニトランザクション（mtr）ログバッファに 確保されているスペースが不足していました。（Bug #29524260） ・InnoDB：VATS（Variance-Aware Transaction Scheduling）の実装の不正確さにより、 MySQLのUBSanビルドで符号付き整数オーバーフローエラーが発生しました。 （Bug #29508517、Bug #91959） ・InnoDB：rw-lockの実装におけるメモリバリアが不十分なため、ARMでデッドロックが発生しました。 （Bug #29508001、Bug #94699） ・InnoDB：UNDOテーブルスペースの暗号化を有効にした後、 INFORMATION_SCHEMA.INNODB_TABLESPACES ENCRYPTIONカラムが更新されませんでした。 （Bug #29492911、Bug #94665） ・InnoDB：前方にスラッシュ文字（/）を含むスキーマまたはテーブルの名前の解析が正しくないため、 再配置されたテーブルにアクセスできませんでした。スラッシュ文字は、サーバーによって誤って ディレクトリセパレータとして解釈されていました。（Bug #29492113） ・InnoDB：様々な修正と改正がInnoDB memcachedのソースコードに加えられました。（Bug #29485891） ・InnoDB：グローバルアクセスを可能にするために、innodb_directories変数の値は、現在、 静的変数ではなくグローバル変数として内部的に格納されます。（Bug #29471990） ・InnoDB：デバッグビルドで、thd_innodb_tmpdir()関数はNULL引数を受け付けませんでした。 （Bug #29471846） ・InnoDB：ファイルスペース割り当てコードの減算操作は、その結果を符号なし変数として誤って 格納し、アサーションエラーが発生しました。（Bug #29466680） ・InnoDB：デフォルトのundoテーブルスペースを移動または削除し、 新しいinnodb_undo_directory値を使用してサーバーを再起動した後、MySQLは新しい場所に undoテーブルスペースを再作成しましたが、データディクショナリ内のundoディレクトリパスの 更新に失敗しました。（Bug #29461900） ・InnoDB：リカバリー中にトランザクションをロールバックしている間に、 以前に解放されたLOBページにアクセスしました。（Bug #29440408） ・InnoDB：リカバリー中に、読み取られるページがない時に、バッファプールにページを読み取るための リクエストが発行されました。不要な読み取りリクエストを回避するためにチェックが追加されました。 （Bug #29440208） ・InnoDB：MySQL 8.0.14で発生したリグレッションにより、 lower_case_table_names=1のMySQLインスタンスにパーティションテーブルを作成すると、 “Invalid (old?) table or database name”エラーが発生しました。 リグレッションの原因となった変更は元に戻されました。（Bug #29426720、Bug #94519） 参考：この問題は、Bug #26925260のリグレッションです。 ・名前にハイフンを使用したデータベースのMySQL 5.6で作成されたFULLTEXTインデックステーブルは、 MySQL 5.7からMySQL 8.0へのアップグレード後に起動エラーを発生させました。 FULLTEXT補助テーブルのテーブルスペースファイルパスがデータディクショナリーに 見つかりませんでした。また、データベース名のハイフンが、その後に生成されたファイルパスで 正しく処理されませんでした。（Bug #29411899、Bug #94431） ・InnoDB：REDOログが論理的に空ではなく単一ブロックで構成されており、挿入バッファマージが 新しいREDOレコードを生成した後、新しいレコードがディスクにフラッシュされる前にサーバーが リカバリ中に終了した場合、データロスが発生する可能性がありました。 （Bug #29411832、Bug #94448） ・InnoDB：Windows上でパスとファイル名がMAX_PATHの制限を超えたテーブルスペースを 作成しようとすると、InnoDBが不明な一般エラーを返しました。InnoDBは、現在、 よりわかりやすいエラーを返します。 （Bug #29341634） ・InnoDB：undoテーブルスペースファイルは、別のディレクトリに移動された後、 見つかりませんでした。（Bug #29328158） ・InnoDB：サーバーがinnodb_buffer_pool_size=defaultの設定で起動できませんでした。 デフォルト値は、依存するシステム変数設定との互換性についてはチェックされませんでした。 （Bug #29267814、Bug #94065） ・InnoDB：CREATE TABLESPACE ... ADD DATAFILE句は、もう循環ディレクトリ参照を許可しません。 例えば、以下のステートメントの循環ディレクトリ参照（/../）は許可されていません。 CREATE TABLESPACE ts1 ADD DATAFILE ts1.ibd 'any_directory/../ts1.ibd'; この制限に対する例外はLinuxに存在しており、Linuxでは先行ディレクトリが シンボリックリンクである場合に循環ディレクトリ参照が許されます。例えば、 上記の例のデータファイルパスは、any_directoryがシンボリックリンクの場合に 許可されます。（データファイルのパスを '../'で始めることは今も許可されています。） アップグレードの問題を回避するためには、MySQL 8.0.17以降にアップグレードする前に、 テーブルスペースデータファイルパスから循環ディレクトリ参照を削除してください。 テーブルスペースのパスを調べるためには、INFORMATION_SCHEMA.INNODB_DATAFILESテーブルに 問い合わせてください。（Bug #29157265） ・InnoDB：MySQLサーバー稼働中に手動でシステム時刻を変更すると、ページクリーナーの スレッド遅延が発生しました。（Bug #29138644、Bug #93708） ・InnoDB：UPDATEステートメントは、エラーが発生した時に必ずしもセミコンシステントな 読み込みを適切に無効にしませんでした。これにより、デバッグモードでアサーションエラーが 発生する可能性がありました。（Bug #29047894） ・InnoDB：削除された行を完全に削除する時、ロック継承を管理するロジックが、 アクティブトランザクションによる制約チェックを満たすために継承されるべき ロックのタイプを正しく決定しませんでした。（Bug #29004362） ・InnoDB：LOCK TABLESモードでプリペアドステートメントを実行すると、暗黙的に開かれた データディクショナリテーブルに不要な読み込みロックがかかりました。（Bug #28875646） ・InnoDB：ログ適用中、OPTIMIZE TABLE操作の後、InnoDBは仮想カラムインデックスの更新を チェックする前に仮想カラムを追加しませんでした。（Bug #28834208） ・InnoDB：クラスタ化されたインデックスからデータをコピーする操作が誤って実行されたため、 空間インデックスはクラスタ化されたインデックスへの古いポインタを持つ空間行を 使用しました。（Bug #28758961） ・InnoDB：生成された仮想BLOBカラムを含むINSERT操作は、誤った値が原因で セカンダリインデックスが更新されるという結果となりました。（Bug #28652826） ・InnoDB：SET PERSIST_ONLY=defaultを使用してinnodb_data_file_pathおよび innodb_temp_data_file_pathを設定すると、誤って変数値がNULLに設定されます。 （Bug #28590014） ・InnoDB：CREATE TABLE ... REPLACE SELECT操作で lock_rec_get_rec_not_gap(lock)アサーションエラーが発生しました。この操作は、 トランザクションオブジェクトにフラグを設定して、REPLACE操作が要求されたことを 示しますが、依存ビューを更新する前にフラグをクリアしなかったため、後に続く INSERT操作はREPLACE操作として解釈され、誤った行ロックが行われました。 （Bug #28523025、Bug #92068） ・InnoDB：super_read_onlyが有効になっている状態で、テンポラリテーブルに対して RENAME TABLE操作を試みると、エラーを返さずにアサーションが発生しました。 （Bug #28490368、Bug #91975） ・InnoDB：仮想インデックスのプレフィックス検索中に初期化されていないバイトが 読み取られたために、Valgrindエラーが報告されました。（Bug #28184025） ・InnoDB：サイズが2GBより大きいシステムテーブルスペースを作成しようとすると、 InnoDBの初期化に失敗しました。（Bug #27538464） ・InnoDB：全文キャッシュサイズが全文キャッシュサイズ制限を超えた場合、データ同期時に 行われる全文キャッシュロックが解除されませんでした。（Bug #25289359） ・InnoDB：INNODB_METRICS metadata_table_reference_countカウンターが負の値を報告しました。 （Bug #20584149、Bug #75966） ・InnoDB：同時挿入操作を実行中の異なるauto_increment_increment値を使用する クライアントセッションは、重複キーエラーを引き起こす可能性がありました。 （Bug #15851528、Bug #67526） 参照：元に戻されたパッチ：Bug #14049391、Bug #65225。 ・パーティショニング：パーティション化されたテーブルの場合、ALTER TABLEステートメントは 以下の条件下で誤ったクエリ結果をもたらす可能性がありました。 * ステートメントが、RENAME COLUMNを使用して直接かDROP COLUMN/ADD COLUMNを 使用した置換によってカラム名を変更することにより、カラムをスワップした。 * スワップされたカラムがパーティショニング式に使用された。 * 変更が、パーティション間で行を再分配しないインプレース操作として実行された。 このようなカラム名の変更は、同じALTER TABLEステートメントが以下の条件の1つを 満たさない限り、禁止されています。 * ステートメントがテーブルを非パーティション化する。 * ステートメントがテーブルのパーティショニングまたはパーティショニング式 （行を再配分するテーブル再構築を引き起こす）を再定義する。これにより、 カラムの名前変更に続いてパーティショニング式が更新されるという既存の シナリオをサポートできる。 * パーティショニングが空のカラムリストを使用してPARTITION BY KEY()で指定される。 これは、カラムの名前変更を追跡するプライマリキーを使用して分割する。 （Bug #29541665、Bug #94792） ・パーティショニング：ALTER TABLE ... EXCHANGE PARTITIONは、交換されるパーティションが 非パーティション化テーブルと同じ行フォーマットを使用している場合でも、 パーティション化されたテーブルに異なる行フォーマットを使用するパーティションがあると、 エラー Non matching attribute 'ROW_FORMAT' between partition and table で失敗しました。 （Bug #28687608） ・レプリケーション：メッセージの断片化が大きなグループレプリケーションメッセージ （MySQL 8.0.16から利用可能でデフォルト）で使用される時に、XComで最も高いノード識別子を 持つグループメンバーによって送信された断片化されたメッセージが部分的に配信され、 その後1人以上のメンバーが残りのメッセージの断片の配信前にグループを去った場合、 メッセージの再構成によってグループレプリケーションが機能しなくなりました。 メンバーがいなくなることは、元の送信者のノード識別子がグループの新しいビューでは もはや有効ではないことを意味しました。 この問題を解決するために、断片化されたメッセージの再構成は、現在、ビュー変更前の 古い状況を反映する最初に配信された断片からではなく、ビュー変更後の新しい状況を 反映する最後に配信された断片からの配信情報を使用します。（Bug #29716639） ・レプリケーション：グループメンバー数と自動インクリメント間隔の間の不一致に対して 発行されるエラーメッセージは、auto_increment_incrementシステム変数ではなく、 group_replication_auto_increment_incrementシステム変数を誤って参照しました。 auto_increment_incrementの値は、グループレプリケーションの開始時に group_replication_auto_increment_incrementで指定された値に変更されますが、 MySQL 8.0以降でauto_increment_incrementおよびauto_increment_offsetにデフォルト値が ある場合のみで、マルチプライマリモードでのみです。auto_increment_incrementの値は、 常にエラーメッセージについてチェックされる値でした。現在、正確なシステム変数名を 指定するように修正されました。（Bug #29542425） ・レプリケーション：レプリケーション内部が依存するシステムテーブルをアップグレードしない MINIMALオプション（--upgrade=MINIMAL）を使用したMySQL Serverのアップグレードの後に グループレプリケーションを開始することはできません。以前、この状況では、サーバーは グループレプリケーションの開始を永久に待っていました。この状況は、現在、待機中の スレッドのブロックを解除し、予想されるエラー ER_GRP_RPL_START_GRP_RPL_FAILEDを 発行することによって正しく処理されます。（Bug #29423358、Bug #94515） ・レプリケーション：グループレプリケーションのグループコミュニケーションシステム （GCS）において、グループを離れているメンバーによる疑いの処理の変更は、いくつかの テストケースの実行時間を短縮したため、リカバリが失敗した場合に問題を引き起こしました。 それがリカバリの失敗とビューの変更通知の間の循環依存関係を引き起こしたためです。 現在、エラーによってリカバリが不可能になった場合、GCSは適切な順序で処理アクションを 実行します。メンバーがグループを離れ、ビューの変更が適用されて、その後 リカバリスレッドが終了します。（Bug #29417365、Bug #29628909） ・レプリケーション：1つのMySQLサーバーインスタンスによって生成されたイベントが別の インスタンスのバイナリログに書き込まれる時、2番目のサーバーは最初のサーバーがそれ自体と 同じ数のバイナリログイベントタイプをサポートすると暗黙のうちに仮定しました。 そうでない場合、イベントヘッダーが正しく処理されませんでした。この問題は修正されました。 （Bug #29417234） ・レプリケーション：グループレプリケーションでは、同じバージョンのメンバーがすでに グループ内に存在していても、参加メンバーは彼ら自身を既存のレプリケーショングループとの 互換性がないと誤って識別してしまう可能性があります。これは、彼らが最も高いバージョンの メンバーを含むすべての他のメンバーに対してチェックを行ったためです。参加メンバーは、 互換性チェックに自分のバージョンも含めました。現在、参加メンバーは自分自身を最も低い バージョンの既存のグループメンバーと比較するだけで、自分のバージョンを数に入れません。 （Bug #29390946、Bug #94429） ・レプリケーション：インスタンスレベルのバックアップロックを取得するために LOCK INSTANCE FOR BACKUPステートメントが使用された場合、STOP SLAVEステートメントが 発行され、バックアップロックを待機しているSQLスレッドと現在のアクションを完了するために SQLスレッドを待っているSTOP SLAVEステートメントで、デッドロックが発生する可能性が ありました。この状況を防ぐために、STOP SLAVEプロセスは、現在、続行する前に バックアップロックを取得しようとし、ロックを取得できない場合はエラーを返します。 （Bug #29386503、Bug #93649） ・レプリケーション：MySQL 8.0.13から、いずれかのレプリケーションチャネルが開いている 一時テーブルを持つ場合、バイナリロギングフォーマットをSET @@global.binlog_format またはSET @@persist.binlog_formatを使用して変更することはできません。以前は、 新しい制限が実装された後にこの操作を試みると、誤ったエラーメッセージがクライアントに 返されました（開いている一時テーブルではなく、実行中のレプリケーションチャネルアプライアを 問題として参照していた）。現在、適切なエラーメッセージが返されます。 （Bug #29370024、Bug #94340） ・レプリケーション：フォーマット記述イベントをデシリアライズする時に バイナリログチェックサムが正しく処理されませんでした。（Bug #29355110） ・レプリケーション：行ベースのレプリケーションを使用している場合、 レプリケーションアプライアスレッドが行変更イベントをアンパックすると、"前"のイメージと "後"のイメージの両方について機能インデックスのインデックス値が計算されました。 "前"のイメージの場合、値は必要ありません。したがって、この計算は、行のアンパックを 最適化するために"前"のイメージについては削除されました。（Bug #29304076） ・レプリケーション：サーバーの再起動後にMEMORYテーブルがマスター上で暗黙的に削除されると、 マスターはスレーブもテーブルを空にするようにバイナリログにDELETEステートメントを 書き込みます。この生成されたイベントは、現在、バイナリログにコメントが含めます。 そのため、DELETEステートメントの理由は簡単に識別できます。（Bug #29157796、Bug #93771） ・レプリケーション：SHOW BINLOG EVENTS FROMステートメントに無効な開始オフセットが 指定された場合、最初に返されたイベントの正しい開始位置の代わりに無効なオフセットが 返されました。（Bug #29039732、Bug #93544） ・レプリケーション：メインの実行中に問題が発生した場合、オンライングループを設定する グループレプリケーションUDFがエラーを返さないことがありました。UDFは、現在、UDFが 初期化を開始する前にグループレプリケーションプラグインが停止しているかどうかも 確認するようになりました。（Bug #28978767、Bug #93372） ・レプリケーション：slave_rows_search_algorithmsシステム変数に 値INDEX_SCAN、HASH_SCAN（MySQL 8.0のデフォルト）が設定されていて、updateイベントが 一意のキーを持たないテーブル内の同じ行に対する2つの更新（ハッシュスキャンが使用される ことを意味する）を含む場合、レプリケーションは“record not found”エラーで停止する 可能性がありました。この状況では、2回目の更新は行変更のためのハッシュスキャンによって 失敗しました。現在、行を更新した後、ハッシュスキャン操作はハッシュマップ内の 更新された行を検索し、それ以降の更新を適用します。 検索がインデックスを使用できないように、 値 TABLE_SCAN、HASH_SCANがslave_rows_search_algorithmsシステム変数に設定されている時、 テーブルに一意のキーがあるかどうかにかかわらず、上記の状況で“record not found”エラーが 発生する可能性があります。また、この設定では、ハッシュスキャンが一意のキーを持つテーブルで 使用された時に、順序に依存する2つの行の更新を含む更新イベントの場合、更新は順不同で適用され、 レプリケーションが重複キーエラーで停止する可能性があります。これらの問題を回避するために、 文書が更新され、値 TABLE_SCAN、HASH_SCANを使用すべきではないと述べられています。 （Bug #28846386） ・レプリケーション：レプリケーションスレーブでバイナリロギングが有効になっている場合、 スレーブで--replicate-same-server-idと--log-slave-updatesオプションを組み合わせると、 サーバーが循環レプリケーショントポロジの一部である場合、レプリケーションで無限ループが 発生する可能性があります。（MySQL 8.0では、バイナリロギングはデフォルトで有効であり、 スレーブの更新ロギングはバイナリロギングが有効である時のデフォルトです。）しかし、 グローバルトランザクション識別子（GTID）の使用は、既に適用されたトランザクションの実行を スキップすることによってこの状況を防ぎます。そのため、現在、gtid_mode=ONが設定されている場合、 このオプションの組み合わせに対する制限は取り除かれています。他のGTIDモードでは、サーバーは このオプションの組み合わせで起動しません。サーバーの始動後に問題の状況を作り出すことに 対する予防策として、このオプションの組み合わせが設定されている稼働中のサーバーで GTIDモードをON以外に変更することはできなくなりました。（Bug #28782370、Bug #92754） ・レプリケーション：グループレプリケーション用のグループ通信エンジン（XCom、Paxosの亜種）は 適切な方法でメモリ不足エラーを処理しませんでした。メッセージのペイロードのコピーを 作成するためにメモリを割り当てることができなかった場合、エラーは記録されましたが、 メッセージはまだ送信され、ペイロードはnullでした。 受信側メンバーのグループコミュニケーションシステム（GCS）はメッセージを空として廃棄し、 受信側メンバーのXComインスタンスはこのアクションを受け入れて再試行しなかったため、 メッセージが事実上スキップされました。これにより、受信側メンバーに設定されているGTIDが グループから分かれ、レプリケーションエラーが発生しました。 XComは、現在、メモリ不足エラーが発生した場合、正常に終了します。そのため、この状況は 発生しません。（Bug #28702320） ・レプリケーション：バイナリログのクエリログイベントで、DROP TABLEステートメントと DELETEステートメントの実行に使用されたスレッドIDが誤って識別されたか、まったく 識別されませんでした。 一時テーブルが含まれている（セッション固有であるため正しいスレッドIDを必要とする） マルチスレッドレプリケーションスレーブでは、mysqlbinlogを使用して ポイントインタイムリカバリのためにバイナリログを再生すると、この見落としによりエラーが 発生しました。スレッドIDは現在正しく設定されます。（Bug #28642318、Bug #92398） ・レプリケーション：トリガがカラムをそのデフォルト値に設定するINSERTステートメント またはUPDATEステートメントを呼び出し、そのカラムのDEFAULT式が非決定論的な場合、 ステートメントベースのレプリケーションでトリガが起動された時、期待される警告が発生しません でした。さらに、バイナリロギング形式がMIXEDの場合、非決定論的ステートメントはROWに 使用される形式ではなく、STATEMENTに使用される形式でログに記録されました。 トリガを起動させるステートメントは、トリガされたステートメントのいずれかが非決定論的であるか どうかを解決時に確認します。現時点では、トリガーされたステートメントは解析されていますが、 解決されていません。そのため、実行され得る唯一のチェックは、トリガーされたステートメントが 非決定論的な演算子を直接参照しているかどうかです。非決定論的な演算子がDEFAULT式で 使用されると、非決定論はトリガーされたステートメントが解決されるまで表示されず、 トリガーの起動時に発生します。 これは、ロギング形式を決定する時に追加のチェックを追加することによって修正されます。 この場合、ステートメントのサブステートメントのいずれかが非決定論的なDEFAULT式を持つカラムを 持つテーブルに書き込むことができる場合、そのステートメントには安全ではないというフラグが 立てられます。DEFAULT式がサブステートメントによって使用されるかどうかは現時点で まだわかっていないため、このチェックは、サブステートメントが非決定論的なDEFAULT式を含む カラムに明示的な値を指定しても、サブステートメントに安全でないというフラグを立てます。 （Bug #28297486） ・レプリケーション：スレーブサーバーがマスターステータスと接続情報をMySQL 8.0の デフォルトであるテーブル（master_info_repository=TABLE）に記録する時、サーバーが スーパーリードオンリーモードの場合(super_read_only=ON)、mysql.slave_master_infoテーブルは シャットダウン時に更新されませんでした。この時点ではエラーログにエラーは書き込まれません でしたが、マスターログファイルとマスターログの位置情報が古いため、サーバーの起動後に レプリケーションに失敗しました。シャットダウン時にマスター情報ログを更新するスレッドは、 現在、他のレプリケーションスレッドと同様に読み取り専用チェックから除外されているため、 サーバーがスーパーリードオンリーモードであっても、テーブルを更新できます。 シャットダウンしているスレーブのエラー処理も改善され、スレーブステータスログへの書き込みに 失敗するとエラーログにエラーが記録されるようになりました。（Bug #27675107、Bug #89987） ・レプリケーション：レプリケーションスレーブが誤ったユーザ名、ホスト、またはポートを 使用してマスターに接続しようとする場合、接続失敗の理由を示す元のエラーメッセージが 一般的なメッセージで上書きされました。この問題は、現在、SHOW SLAVE STATUSステートメント からの出力およびパフォーマンススキーマテーブル replication_connection_statusで 修正されています。（Bug #26580064） ・macOS：DMGパッケージを使用して実行されたmacOSインストールでは、 launchd操作に問題がありました。 * 以前は、preferenceペインでMySQLが起動時に開始するように設定されている場合、 SHUTDOWNが再起動を引き起こしていました。これは、mysqladmin shutdownコマンドにも 影響しました。これらの方法で開始されたサーバーのシャットダウンは、現在、 正しく動作します。 * 以前は、RESTARTは動作しませんでした。現在は、正常に動作します。 * 以前は、サーバーが起動時に開始するように設定されていない場合、予期しないサーバーの 終了によって自動再起動は発生しませんでした。0以外の終了ステータスで終了すると、 現在は、起動時のスタートアップ設定に関係なく再起動します。 （Bug #29789857） ・JSON：JSONデータを返す式でMAX()およびMIN()が使用される場合、これらの値はJSON値ではなく 文字列として比較されることがあり、予期しない結果が生じました。JSON値が数値の場合、 これは特に顕著に見られました。 これは、インデックス付きの一時テーブルを使用している時にGROUP BYがJSON値を正しく 比較しなかったためです。（Bug #28947381） ・JSON：JSON_TABLE()は、ストアド関数から実行された場合、エラー Unknown database '' を 返しました。 この問題の根本的な原因は、JSON_TABLE()を使用したSELECTからテーブルをマージする時に、 MySQLが派生テーブルのみをチェックしたことでした。これにより、JSON_TABLE()によって 返された結果テーブルは通常のテーブルとして示されました。そのため、クエリを実行しようと した時、サーバーはそれを開くことができませんでした。現在、MySQLは追加されるテーブルが 内部テーブル、つまり派生テーブル、JSON_TABLE()結果テーブル、または再帰的共通テーブル式への 参照ではないかどうかをチェックします。（Bug #92976、Bug #28851656） ・GRANTステートメントのWITH ADMINオプションが正しく処理されないことがありました。 （Bug #29900772） ・ユーザーがGRANT OPTION権限を持っているかどうかによって、外部キーのエラーメッセージが 異なる場合がありました。（Bug #29868844） ・アップグレード操作中、オートコミットが無効になっている場合、ヘルプテーブルの アップグレードに失敗しました。（Bug #29865428、Bug #95620） ・小さいtable_open_cacheのサイズで操作しながら、ベクターに動的に割り当てられた ディクショナリオブジェクトをアップグレード中に取得すると、 データディクショナリテーブルが再度開かれ、収集されたオブジェクトを誤って解放した ガベージコレクションメカニズムが起動されました。その後、解放されたオブジェクトに アクセスしようとすると、セグメンテーション違反が発生しました。（Bug #29823053） ・MySQL 5.7から8.0へのアップグレードでは、mysqlシステムスキーマ内の innodb_*_stats_backup57.ibdファイルを削除する前にアップグレードプロセスが クローズしなかったため、その後のファイルシステム操作でエラーが発生しました。 （Bug #29791350） ・ファイルシステムがデータディレクトリのマウントポイントでマウントされ、 lost+foundファイルまたはディレクトリが存在する場合、mysqld --initializeが失敗します。 lost+foundファイルまたはディレクトリは、現在、データディレクトリの初期化中は無視されます。 （Bug #29780434） ・MySQLのアップグレードで、SUPER権限を持つアカウントはAUDIT_ADMIN権限を割り当てられません でした。（Bug #29770732） ・REGEXP_REPLACE()関数は、全ての場合において空文字列を正しく処理しませんでした。 （Bug #29763554） ・ストアドプログラムのローカルオブジェクトのソート中に、非常に厳密なアサーションが 発生する可能性がありました。（Bug #29759547、Bug #95062） ・グループの通信プロトコルのバージョンを問い合わせるため使用される group_replication_get_communication_protocol() UDFは、グループメンバーがRECOVERING状態の 場合、失敗しました。これは不必要な制限でした。現在、それが実行されているメンバーが ONLINE状態にあり、グループの大多数と連絡しているという条件で、このUDFは使用できるように なりました。（Bug #29754967、Bug #95306） ・REPEAT()の引数の中には、最大長の計算が必ずしも正しく処理されないものがありました。 （Bug #29739778） ・CHECK制約のあるテーブルに対するUPDATEステートメントは、制約を強制することができない 可能性がありました。（Bug #29706621、Bug #95189） ・RPMまたはDebianパッケージからのインストールについて、データディレクトリ内の mysql_upgrade_infoファイルが存在することはわかっているがrootに所有されている場合、 現在はデータディレクトリと同じ所有者に変更されます。正しいSELinuxファイルコンテキストも 設定されます。（Bug #29704041） ・RPMパッケージからインストールすると、不正な権限でエラーログが発生する可能性がありました。 （Bug #29702462） ・前回のアップグレード中にmysql_upgradeプログラムによって作成されたmysql_upgrade_info ファイルは、mysql_upgradeプログラムを実行したオペレーティングシステムユーザーのみが 変更でき、アップグレードエラーを引き起こしました。現在は、エラーの代わりに警告が 発行され、アップグレード操作を続行できるようになりました。mysql_upgrade_infoファイルは 推奨されておらず、将来のMySQLバージョンで削除される予定です。（Bug #29702060、Bug #95165） ・監査ログ暗号化を有効にすると、サーバーが終了する可能性がありました。（Bug＃29549327） ・DebianとUbuntuでは、MySQLパッケージは、MySQLのネイティブパッケージからアップグレードした後、 mysql.serviceを有効にしませんでした。（Bug #29435592） ・サーバーがエラー発生時に共有メモリ接続を正しくクローズしなかったため、予期しない サーバー動作が発生する可能性がありました。（Bug #29435426） ・開発コンポーネントが選択されなかった場合、MySQLインストーラーはOpenSSL DLLの依存関係を インストールしませんでした。（Bug #29423421、Bug #94168） ・パーサーが複数ステートメントのクエリに対してメモリリークを起こす可能性がありました。 （Bug #29419820） ・HANDLERステートメントは、カラムを生成したテーブルで必ずしも正しく動作しませんでした。 （Bug #29300049） ・クライアント／サーバーのプロトコルのセッション追跡情報が誤って処理される可能性がありました。 （Bug #29297652） ・PAD_CHAR_TO_FULL_LENGTH SQLモードが有効な場合、パスワードの変更に失敗し、警告やエラーは 報告されませんでした。（Bug #29287785） ・audit_logプラグインはUNINSTALL PLUGIN audit_logステートメントをログに記録しませんでした。 （Bug #29248047） ・audit_logのフィルタリング操作によりメモリリークが発生する可能性がありました。（Bug #29201747） ・いくつかのパフォーマンススキーマテーブルを削除するための権限が正しくチェックされませんでした。 （Bug #29010031） ・ORDER BYを含む派生テーブルを使用したクエリは、必ずしも正しく処理されませんでした。 （Bug #28942965） ・基本カラムは、生成されたカラムによるインデックスのみのアクセスから除外されませんでした。 （Bug #28652733） 参照：Bug #29664369。この問題はBug #23169112のリグレッションです。 ・スレッドプロセスのティックタイムが最大許容値を超えると、スレッドプールグループが ブロックされる可能性がありました。ティックタイムは、現在、より大きな値を許可するために より大きなデータ型を使用します。（Bug #28072609） ・MySQLは、OpenSSLのセッションチケットをサポートしていませんが、 それをOpenSSLに通知するためのSSL_OP_NO_TICKETフラグを設定しませんでした。 現在、フラグは設定されます。（Bug #27655493） ・audit_nullプラグインはnullイベントレコードを適切にチェックしませんでした。（Bug #27638290） ・UpdateXML()は特定のケースで必ずしも適切にメモリを解放しませんでした。（Bug #27312862） ・mysql.pluginシステムテーブルのnameカラムに空の値があると、サーバーが起動中に終了しました。 （Bug #27302459） ・thread_poolプラグインが有効な場合、パフォーマンススキーマのstatus_by_threadテーブルには データが含まれませんでした。（Bug #25933891） ・INSTALL PLUGINステートメントが共有ライブラリ名に無効なUTF-8文字を含む場合、サーバーが ハングアップする（または、デバッグビルドでアサーションが発生する）原因になりました。 （Bug #14653594、Bug #23080148、Bug #27167197）
全ての変更点やバグ修正については、以下のページをご覧ください。
MySQL 8.0.17リリースノート（MySQLウェブサイト）：
http://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-17.html
MySQL Editions
MySQLのサブスクリプションは、24時間365日体制でお客様をサポートいたします。さらに MySQL Enterprise Edition では、データベース管理者支援ツール MySQL Enterprise Monitor やバックアップツール MySQL Enterprise Backup をご利用いただけます。