主な変更点
■ アカウント管理関連
・以前は、各MySQLユーザーアカウントは単一のパスワードを持つことを許可されていました。 現在、MySQLはアカウントがプライマリパスワードとセカンダリパスワードとして指定された デュアルパスワードを持つことを許可しています。 この機能により、複雑なマルチサーバーシステムで、ダウンタイムなしで、段階的な パスワード変更をシームレスに実行できます。デュアルパスワード機能をサポートするために、 アカウントに新しいプライマリパスワードを割り当てる時、ALTER USERステートメントと SET PASSWORDステートメントに現在のパスワードをセカンダリパスワードとして保存する RETAIN CURRENT PASSWORD句が追加されました。ALTER USERには、不要になった セカンダリパスワードを破棄するためのDISCARD OLD PASSWORD句もあります。 ＜重要＞ デュアルパスワード機能の実装には、mysql.userシステムテーブルの構造に対する変更が伴います。 以前のバージョンからこのMySQLリリースにアップグレードする場合、mysql_upgradeを実行して （そしてサーバーを再起動して）、このシステムデータベースの変更を組み込む必要があります。 これが行われるまで、パスワードの変更はできません。
■ 監査ログ関連
・監査APIにより、audit_api_message_emit_udf() ユーザ定義関数を含む新しい audit_api_message_emitコンポーネントを使用して、アプリケーションが 独自のメッセージイベントを監査ログに追加できるようになりました。
■ コンパイル関連
・サーバービルド用のBoostライブラリの最小バージョンは現在1.68.0です。(Bug #28478497)
■ コンポーネント関連
・サーバーコンポーネントがホストアプリケーションに信号を送信できるようにするために、 新しいhost_application_signalコンポーネントサービスが使用できます。例えば、 このサービスによって、複製コンポーネントはサーバーにシャットダウン信号を送信できます。
■ 設定関連
・.gitignoreファイルの内容が整理されました。このファイルの多くは、以前からある.bzrignoreから 継承されたもので、関連性はありませんでした。このクリーンアップの1つの意味は、 インソースビルドは許可されていないということです。（Bug＃28341794、Bug＃91626） ・MySQL Serverは、現在、TCP/IPポートが管理接続専用に設定されることを許可しています。 これは、max_connections接続がすでに確立されている場合でも、通常の接続に使用される ネットワークインタフェースで許可されている単一の管理接続に代わるものを提供します。 管理ネットワークインタフェースには、次の特性があります。 * このインタフェースは、admin_addressシステム変数が起動時に設定され、 管理インタフェース用のIPアドレスを示す場合にのみ使用可能です。 * admin_portシステム変数は、インターフェースのTCP/IPポート番号を指定します （デフォルトは33062）。 * 管理接続数に制限はありません。 * 接続は、SERVICE_CONNECTION_ADMIN権限を持つユーザーによってのみ許可されます。 create_admin_listener_threadを使用すると、データベース管理者は、管理インタフェースが 通常の接続に使用されるリスナースレッドを使用して実装されるか（デフォルト）、 独自のスレッドを使用するかを選択できます。 (Bug #27847672, Bug #90395)
■ 廃止予定と削除
・廃止予定のresolveipおよびresolve_stack_dumpユーティリティは削除され、 MySQLディストリビューションには含まれなくなりました。resolveipの代わりに、nslookup またはhost、digを使用できます。公式のMySQLビルドからのスタックトレースは、 常にシンボル化されているので、resolve_stack_dumpを使用する必要はありません。
■ 関数関連
・JSON_ARRAYAGG（）とJSON_OBJECTAGG（）の集計関数は、OVER句があればウィンドウ関数として 使用できるようになりました。
■ ロギング関連
・新しいシステム変数log_slow_extraが有効になっている場合、サーバーはスローステートメントに 関する情報を提供するスロークエリログに追加のフィールドを書き込みます。さらに、 ステートメントのタイムスタンプを示すためにログに書き込まれたSET行は、実行終了時ではなく、 ステートメント実行開始時からの時間を使用するようになりました。(Bug #27535580, Bug #89637) ・バイナリログファイルとリレーログファイルを暗号化できるようになり、これらのファイルとそこに 含まれる機密である可能性があるデータが外部の攻撃者に悪用されたり、保存されている オペレーティングシステムのユーザーによる不正な閲覧から保護されます。 MySQLサーバーで暗号化を有効にするためには、新しいbinlog_encryptionシステム変数をONに 設定します。デフォルトはOFFです。このシステム変数は、バイナリログファイルと リレーログファイルの暗号化をONに設定します。暗号化を有効にしてサーバーを初めて起動する時、 バイナリログとリレーログが初期化される前に新しいバイナリログ暗号化キーが生成されます。 このキーは、各バイナリログファイル（サーバーでバイナリロギングが有効になっている場合） およびリレーログファイル（サーバーにレプリケーションチャネルがある場合）の ファイルパスワードを暗号化するために使用されます。そして、ファイルパスワードから生成される その他のキーは、ファイル内のデータを暗号化するために使用されます。 サーバーの稼働中に暗号化を有効にすると、その時点で新しいバイナリログ暗号化キーが生成され、 新しいファイルとそれ以降のファイルが暗号化されるためにバイナリログファイルとリレーログファイルが ローテーションされます。binlog_encryptionシステム変数をOFFに変更して暗号化を無効にすると、 バイナリログファイルとリレーログファイルはすぐにローテーションされ、それ以降のすべてのログ記録は 暗号化されません。以前に暗号化されたファイルは自動的に復号化されませんが、サーバーはまだ それらを読むことができます。（SHOW BINARY LOGSステートメントは、各バイナリーログファイルが 暗号化されているかどうかを示すようになりました。）サーバーの稼働中に暗号化を有効または無効にする ためには、SUPER権限または新しいBINLOG_ENCRYPTION_ADMIN権限が必要です。 ファイルに使用される暗号化アルゴリズム、AES（Advanced Encryption Standard）暗号化アルゴリズム は、MySQL Serverに組み込まれており、設定することはできません。ログファイルの ファイルパスワードを暗号化するために使用されるバイナリログ暗号化キーは、MySQLサーバーの 組み込みキーリングサービスを使用して各MySQLサーバーインスタンスに対して特別に生成される 256ビットキーです。サーバーで現在使用されているバイナリログ暗号化キーは、 バイナリログマスターキーと呼ばれます。 新しいbinlog_rotate_encryption_master_key_at_startupシステム変数は、サーバーの再起動時に バイナリログマスターキーが自動的にローテーションされるかどうかを制御します。このシステム変数が ONに設定されている場合、サーバーが再起動されるたびに、新しいバイナリログ暗号化キーが生成され、 新しいバイナリログマスターキーとして使用されます。デフォルトであるOFFに設定されている場合、 既存のバイナリログマスターキーは再起動後に再度使用されます。 MySQLサーバーインスタンスで暗号化が有効になっている場合、バイナリログファイルと リレーログファイルに書き込まれている保存データのみが暗号化されることに注意してください。 mysqlbinlogを含むMySQLクライアントに送信されるレプリケーションイベントストリーム内の 移動中のデータは常に暗号化されていない形式であるため、接続暗号化を使用して転送中保護される 必要があります。トランザクション中にバイナリログトランザクションおよびステートメントキャッシュに 保持されている使用中のデータ、および、それらのキャッシュで使用可能な領域を超えてディスク上の 一時ファイルに格納されているデータも暗号化されていない形式です。トランザクションを処理する スレッドが終了すると、一時ファイルとキャッシュは削除されます。 ・ロギング設定を指定する起動オプションを処理する前に生成されるエラーログメッセージに関して、 サーバーのロギング動作が変更されました。以前は、サーバーはデフォルトのタイムスタンプ、 フォーマット、および詳細レベルでメッセージを生成し、それらをバッファし、それから、 エラーログの設定が確認された後にそれらをフラッシュしました。これらの初期のメッセージは デフォルトのロギング設定を使用していたため、起動オプションで指定されたものとは異なる可能性が ありました。 現在、サーバーはフォーマットされたログメッセージではなくログイベントをバッファします。 これにより、設定が確認された後にそれらのイベントにその設定を遡って適用することができ、 その結果、フラッシュされたメッセージはデフォルトではなく設定された設定を使用します。
■ オプティマイザ関連
・以前は、派生テーブルや共通テーブル式に外部参照を含めることはできませんでした。 外部参照は現在許可されています。
■ パッケージング関連
・Ubuntu 18.10とFedora 29はデフォルトでOpenSSL 1.1.1をインストールしますが、 OpenSSL 1.1.1はMySQLで完全にはサポートされていません。MySQLをインストールするためには、 OpenSSL 1.0.2の互換パッケージをインストールする必要があります。(Bug #28981868)
■ パフォーマンススキーマ関連
・パフォーマンススキーマステートメントイベントテーブル（events_statements_current、 events_statements_history、events_statements_history_long）に、SQLレベルで サーバーによって保持されるクエリIDを示すSTATEMENT_ID列が追加されました。 列の値は、アトミックに増分されるグローバルカウンタを使用して生成されるため、 サーバーインスタンスに対して一意です。
■ プラガブル認証
・LDAPポート番号が636または3269に設定されている場合、プラグインはLDAPではなく LDAPS（LDAP over SSL）を使用するようになりました。ポート番号はシステム変数の authentication_ldap_sasl_server_portまたはauthentication_ldap_simple_server_portを 使用して設定できます。（LDAPSはstartTLSとは異なります。）(Bug＃28743563) ・以前は、プロキシを使用したLDAP認証では、LDAP認証プラグインはLDAPサーバーから返された 最初のグループ名をMySQLプロキシユーザーアカウント名として使用していました。 MySQLアカウントの認証文字列は、一致するグループのリストを優先順に指定できるように なりました。また、オプションで、一致するグループ名を指定されたMySQLプロキシユーザー名に マッピングできるようになりました。
■ セキュリティ関連
・一部のプラットフォーム（Windows、macOS、Generic Linux）でMySQLにバンドルされている OpenSSLライブラリは、バージョン1.0.2qにアップグレードされました。 他のすべてのプラットフォームでは、MySQLはシステムにインストールされたOpenSSLを使用します。 新しいOpenSSLバージョンで修正された問題は以下のページで説明されています。 http://www.openssl.org/news/vulnerabilities.html (Bug＃28988091) ・その後のサーバーの再起動に影響を与えるために、SET PERSISTおよびSET PERSIST_ONLY ステートメントはシステム変数がデータディレクトリのmysqld-auto.cnfオプションファイルに 永続化されることを可能にします。しかしながら、システム変数の中には永続化できないものが あります（たとえば、機密データに関係するため）。そのため、それらはリモート管理者によって 実行されるセッション内から実行時に設定されることはできず、そのため、管理者は サーバーホストにログインしてmy.cnfオプションファイルを直接変更する必要があります。 MySQLでは、以前は永続化できなかった多くのシステム変数のランタイム管理をユーザーが 実行できるようになりました。そのため、特定の制限的な条件下で永続化できます。 この機能を有効にするためには、これらの制限されたシステム変数を永続化する機能を示す SSL証明書X.509のSubject値を指定し、新しいpersist_only_admin_x509_subjectシステム変数を そのSubject値に設定します。暗号化された接続を使用してサーバーに接続し、 指定されたSubject値を含むSSL証明書を提供するユーザーは、SET PERSIST_ONLYを使用して 永続化に制限のあるシステム変数を永続化することができます。 ・ほとんどのシステム変数に関して、セッション値の設定は特別な権限を必要とせず、現在のセッションに 影響を与えるためにどのユーザーでも行うことができます。一部のシステム変数に関しては、 セッション値を設定すると現在のセッションではないところで影響を及ぼす可能性があるため、 特別な権限を持つユーザーだけが行える制限された操作になります。以前は、 SYSTEM_VARIABLES_ADMINまたはSUPERのいずれかがそのような権限としての資格がありましたが、 どちらの権限もセッション変数の設定以外の操作も許可しています。 新しいSESSION_VARIABLES_ADMIN権限は、制限されたセッション変数を設定する権限のみを ユーザーに与えることを可能にし、他の操作も可能するということはありません。 SESSION_VARIABLES_ADMINによって許可された操作は、SYSTEM_VARIABLES_ADMINまたはSUPERに よっても許可されます。したがって、後者の権限の1つをすでに持っているユーザーは、 事実上、暗黙的にSESSION_VARIABLES_ADMINを持ち、明示的にSESSION_VARIABLES_ADMINを 付与される必要はありません。しかしながら、制限付きセッションのシステム変数を 変更できるようにする目的のみのためにユーザーがSYSTEM_VARIABLES_ADMINまたはSUPERを 付与されている場合、管理者はSYSTEM_VARIABLES_ADMINおよびSUPERを取り消し、代わりに SESSION_VARIABLES_ADMINを付与することによってユーザーの権限フットプリントを減らすことが できます。 以前は制限されていた次のセッション変数はSYSTEM_VARIABLES_ADMINまたはSUPERを 必要としましたが、現在はSESSION_VARIABLES_ADMINでも設定されることが可能です。 binlog_format binlog_row_image binlog_row_value_options binlog_rows_query_log_events debug debug_sync default_collation_for_utf8mb4 explicit_defaults_for_timestamp gtid_next histogram_generation_max_mem_size original_commit_timestamp sql_log_bin sql_log_off sql_require_primary_key1234567891011121314 以前は制限されていなかった次のセッション変数は現在制限されており、設定するためには 少なくともSESSION_VARIABLES_ADMINが必要です（SYSTEM_VARIABLES_ADMINまたはSUPERを持つ ユーザーもそれらを設定することができます）。 auto_increment_increment auto_increment_offset binlog_direct_non_transactional_updates bulk_insert_buffer_size character_set_filesystem character_set_database collation_database pseudo_slave_mode pseudo_thread_id rbr_exec_mode transaction_write_set_extraction mysql> SET @ssn = gen_rnd_ssn(); mysql> SET @masked_ssn1 = mask_ssn(@ssn); mysql> SET @masked_ssn2 = mask_outer(mask_inner (@ssn,4,5,'A'), 3,0,'B'); mysql> SELECT @ssn, @masked_ssn1, @masked_ssn2; +-------------+--------------+--------------+ | @ssn | @masked_ssn1 | @masked_ssn2 | +-------------+--------------+--------------+ | 980-31-2838 | XXX-XX-2838 | BBB-AA-2838 | +-------------+--------------+--------------+
■ 空間データサポート
・ST_Distance()関数は、戻り値の単位を指定できるようにするためのオプションの3番目の引数を 取ります。許容される単位は、新しいINFORMATION_SCHEMA ST_UNITS_OF_MEASUREテーブルに リストされている単位です。
■ SQL構文
・派生テーブルは、同じFROM句の中の先行テーブルの列の参照（依存）を許可されていることを 指定するために、LATERALキーワードを前に付けられる可能性があります。 LATERALで指定される派生テーブルは、コンマで区切られたテーブルのリストまたは結合仕様 （JOIN、INNER JOIN、CROSS JOIN、LEFT [OUTER] JOIN、またはRIGHT [OUTER] JOIN）の いずれかで、FROM句でのみ指定できます。ラテラル派生テーブルは、非ラテラル派生テーブルでは 実行できない特定のSQL操作や効率の悪い回避策を必要とする特定のSQL操作を可能にします。 ＜注意＞ LATERALは現在予約語であり、識別子引用符を付けないと識別子として使用できません。
■ スレッドプール関連
・スレッドプールプラグインがインストールされた状態のINFORMATION_SCHEMAテーブルは、 PERFORMANCE_SCHEMAテーブルに移行されました。INFORMATION_SCHEMAテーブルは廃止予定で、 将来のMySQLバージョンで削除される予定です。アプリケーションは、古いテーブルから 新しいテーブルに移行する必要があります。例えば、アプリケーションが次のクエリを 使用するとします。 SELECT * FROM INFORMATION_SCHEMA.TP_THREAD_STATE;1 アプリケーションは代わりに次のクエリを使用する必要があります。 SELECT * FROM performance_schema.tp_thread_state;1
■ Xプラグイン関連
・Xプラグインはエラー処理クラスに5桁のSQLSTATEエラーコードを追加しました。 以前は、SQLSTATEエラーコードはSQLエラーについてクライアントに返されていましたが、 MySQL固有のエラー番号のみが公開されていました。(Bug＃28735058) ・ドキュメントの集まりを問い合わせる時、boolean値がSQLクエリのプレースホルダの 引数として使用された場合、予期しない結果が返されました。 このような状況で正しく処理されるように、新しい変換機能がboolean値用に追加されました。 (Bug＃28227037) ・Xプロトコルは、取得したデータを返す前に常に（utf8mb4_general_ci照合を使用して） utf8mb4キャラクターセットに変換するようになりました。(Bug＃28180155) ・XプロトコルはSQL準備機能に対応しました。
■ 追加・変更された機能
・InnoDB: コアファイルのサイズを減らすために、innodb_buffer_pool_in_core_file変数を無効にして
InnoDBバッファプールページがコアファイルに書き込まれないようにすることができます。
(Bug #27724476、Bug #90144)
・InnoDB: デフォルトでは、UNDOログはMySQLインスタンスの初期化時に作成される2つの
UNDOテーブルスペースにあります。
CREATE UNDO TABLESPACE構文を使用して、実行時に選択した場所に、追加のUNDOテーブルスペースを
作成することができます。
CREATE UNDO TABLESPACE tablespace_name ADD DATAFILE 'file_name.ibu';1
CREATE UNDO TABLESPACE構文を使用して作成されたUNDOテーブルスペースは、
DROP UNDO TABLESPACE構文を使用して実行時に削除できます。
DROP UNDO TABLESPACE tablespace_name;1
ALTER UNDO TABLESPACE構文を使用して、UNDOテーブルスペースをアクティブまたは非アクティブとして
マークできます。
ALTER UNDO TABLESPACE tablespace_name SET {ACTIVE|INACTIVE};1
テーブルスペースの状態を示すSTATE列がINFORMATION_SCHEMA.INNODB_TABLESPACESテーブルに
追加されました。UNDOテーブルスペースは、削除される前に空の状態になっている必要があります。
以前は非推奨だったinnodb_undo_tablespaces変数は設定できなくなり、将来のリリースで削除される
予定です。
・InnoDB: InnoDBは並列クラスタ化インデックスの読み取りをサポートするようになり、これは
CHECK TABLEのパフォーマンスを改善できます。この機能はセカンダリインデックススキャンに
適用されません。 innodb_parallel_read_threadsセッション変数は、並列クラスタ化インデックスの
読み取りが行われるために1より大きい値に設定する必要があります。デフォルト値は4です。
並列クラスタ化インデックスの読み取りを実行するために使用される実際のスレッド数は、
innodb_parallel_read_threads設定またはスキャンするインデックスサブツリーの数のどちらか
小さい方によって決まります。
・InnoDB: CREATE TABLESPACEステートメントのADD DATAFILE句はオプションになりました。
これにより、FILE権限を持たないユーザーもテーブルスペースを作成することができます。
ADD DATAFILE句を指定せずに実行されたCREATE TABLESPACEステートメントは、
一意のファイル名でテーブルスペースデータファイルを暗黙的に作成します。
・InnoDB: innodb_dedicated_server変数を有効にすると、ログファイルのサイズと数が、
自動的に設定されたバッファプールサイズに従って設定されるようになりました。
以前は、ログファイルのサイズはサーバーで検出されたメモリの量に従って設定され、
ログファイルの数は自動的に設定されませんでした。
・レプリケーション：シングルプライマリモードでグループを実行している時、バックログに
保持されているトランザクションが適用されている間に新しいプライマリが選択された場合、
新しいプライマリに対する読み込み操作が古い値を返す可能性がありました。現在、
group_replication_consistency変数を使用して、この状況でのグループの動作を制御できます。
group_replication_consistencyがEVENTUALに設定されていると、まだ適用されていない
バックログがあっても新しいプライマリが読み取り要求に応答します。これは以前の動作と
一致し、バックログの適用されている間にクライアントが古い値を読み取る可能性があります。
super_read_onlyモードが有効になっているため、新しいプライマリへの書き込みはこの期間中は
失敗します。group_replication_consistencyがBEFORE_ON_PRIMARY_FAILOVERに設定されていると、
古いプライマリからバックログを適用している、新しく選択されたプライマリに対する
新しい読み取りまたは書き込みクエリは、バックログが適用されるまで保持されます。
これにより、クライアントは常に自分が書き込んだ最新の値を読み取ることができます。
しかし、クライアントは、新しいプライマリから読み取ることができるようになる前に
バックログが適用されるまで待機しなければならない可能性もあります。
参照: Bug #26004894
・Microsoft Windows: MySQLサーバーによって作成された名前付きパイプでクライアントに与えられる
アクセスコントロールは、Windows上で通信を成功させるために最低限必要なものに設定されています。
新しいMySQLクライアントソフトウェアは、追加の設定なしで名前付きパイプ接続を開くことが
できます。古いクライアントソフトウェアをすぐにアップグレードできない場合は、
新しいnamed_pipe_full_access_groupサーバーシステム変数を使用して、名前付きパイプ接続を
開くために必要な権限をWindowsグループに付与できます。フルアクセスグループのメンバーシップは
制限された一時的なものにする必要があります。
・最小サーバーRPMは、主にDockerイメージに使用されます。Dockerとの互換性を高めるために、
log-error行はrpm-docker設定ファイルから削除されました。このようにして、
標準出力/標準エラー出力にロギングされるメッセージは、Docker独自のインターフェースを
使用できます。(Bug #28692675)
・外部キーの作成および削除に関するエラーメッセージがより具体的かつ有益になるように改善されました。
(Bug #28526309, Bug #92087)
・文字セット変換を試みたが失敗したALTER TABLEステートメントのエラーメッセージは、どの列が
エラーを発生させたかを示すように改善されました。(Bug #27546306, Bug #88738)
・以前は、数値をとるコマンドオプションでは、乗数1024、10242、10243を示すために、K、M、Gの
接尾辞を付けて値を指定することができました。現在、乗数10244、10245、10246を示すために、
接尾辞をT、P、Eにすることもできます。(Bug #27306931, Bug #89017)
・スケーラビリティとパフォーマンスを向上させるために、リソースグループのロックが修正されました。
(Bug #27148580)
・グループレプリケーションのグループ通信システム（GCS）およびグループ通信エンジン
（XCom、Paxosの一種）はIPv6を完全にサポートするようになり、そのため、
レプリケーショングループのメンバーは、内部グループ通信のIPv4アドレスの代わりに
IPv6アドレスを使用できます。IPv6のローカルホストアドレス、および、IPv6の
プライベートサブネットワークアドレス（固有ローカルアドレスとリンクローカルユニキャストアドレス）
は、手動のホワイトリストが指定されていない場合の使用のためにグループレプリケーションの
自動ホワイトリストに追加されます。
レプリケーショングループのすべてのメンバーが、グループレプリケーションのための
IPv6アドレスの使用をサポートするMySQLサーバーバージョンである場合、
グループにはIPv6アドレスを使用するメンバーとIPv4アドレスを使用するメンバーの混在が
含まれる可能性があります。参加メンバーは、接続のためにシードメンバーによって提供される
プロトコルと一致するホワイトリストIPアドレスまたはホスト名を提供する必要がありますが、
参加メンバーのメイン識別アドレスまたはホスト名（group_replication_local_address）は
どちらのプロトコルも使用できます。メンバーがIPv4アドレスとIPv6アドレスの両方に
解決されるホスト名を使用する場合、IPv4アドレスが常にグループレプリケーション接続に
使用されます。
レプリケーショングループの一部またはすべての既存のメンバーが、グループレプリケーションの
ためのIPv6アドレスの使用をサポートしていない古いバージョンのMySQL Serverを使用している場合、
参加メンバーはgroup_replication_local_addressオプションにグループ通信用のIPv4アドレスを
提示する必要があります。すべてのグループメンバーがアップグレードされたら、グループを
IPv6アドレスに移行できます。(Bug #26088469, Bug #27757729, Bug #90217)
・MySQLグループレプリケーションは、TCPソケットを使用する代わりに、専用の入力チャンネルを使用して
通信できるようになりました。新しい入力チャネルは、グループレプリケーションロジックと
基礎となるグループ通信エンジン（XCom、Paxosの一種）のローカルインスタンスとの間の通信に
共有メモリを使用します。
以前は、ローカルXComインスタンスとの通信は、常にTCPソケット、つまり各グループメンバーの
group_replication_local_addressシステム変数で指定されたネットワークアドレスを使用して、
行われていました。これにより、ネットワークプロトコルスタックを介したメモリのコピーや
データのシリアル化など、ローカル通信に不要なオーバーヘッドが発生しました。
各グループメンバーがリモートXComインスタンスと通信するに、TCPソケット
（group_replication_local_address）が今でも必要です。グループレプリケーションの
グループ通信システム（GCS）コンポーネントは、各グループレプリケーションタスクに
最も適した通信方法（入力チャネルまたはTCP）を選択するようになりました。例えば、
グループに参加するプロセスは、リモートXComインスタンスとの通信を必要とするため、
TCPを使用する必要があります。しかしながら、グループからメンバーを削除するプロセスでは、
ローカルのXComインスタンスとの通信のみが必要なため、入力チャネルが使用されます。
ネットワーキングメカニズムを使用した通信に関連するオーバーヘッドを最小限に抑えるために、
入力チャネルは可能な限り選択されます。
・レプリケーションによる内部使用のために、2つの新しいセッションシステム変数が追加されました。
original_server_versionとimmediate_server_versionは、レプリケーショントポロジを通じて
トランザクションに関連付けられたMySQLサーバーのリリース番号を送信することで、
クロスバージョンレプリケーションをサポートします。original_server_versionは、
トランザクションが最初にコミットされたサーバーのMySQL Serverリリース番号を保持します
（例えば、MySQL 8.0.14サーバーインスタンスの場合は80014）。immediate_server_versionは、
レプリケーショントポロジで直接のマスタであるサーバーのMySQLサーバリリース番号を保持します。
これらのサーバーのいずれか、または、レプリケーショントポロジ内に介在する別のサーバーが、
これらのセッションシステム変数をサポートしていない古いリリースのものである場合、
それらの値は0に設定されます。
関係するリリース間で構文の変更または意味上の変更が発生した箇所を認識し、それらを適切に
処理することによって、この情報を使用して、スレーブは古いリリースのマスターから発生する
データを正しく処理できます。この情報は、レプリケーショングループの1つ以上のメンバーが
他のメンバーよりも新しいリリースにあるグループレプリケーション環境でも使用できます。
変数の値は各トランザクションのバイナリログで（Gtid_log_eventの一部として、または、
サーバーでGTIDが使用されていない場合はAnonymous_gtid_log_eventの一部として）表示でき、
クロスバージョンレプリケーションの問題のデバッグに役立ちます。
・起動オプション--binlog-row-event-max-sizeに、対応するシステム変数binlog_row_event_max_size
が追加されました。起動オプションとシステム変数は、行ベースのバイナリログイベントの最大サイズに
対する弱い制限を設定し、デフォルト設定は8192バイトです。可能であれば、
バイナリログに保存された行は、この設定の値を超えないサイズのイベントにまとめられます。
イベントを分割できない場合は、最大サイズを超えることがあります。
binlog_row_event_max_sizeグローバルシステム変数は読み取り専用で、サーバーの起動時にのみ
設定できます。したがって、その値は、SETステートメントでPERSIST_ONLYキーワードまたは
@@persist_only修飾子を使用することによってのみ変更することができます。
システム変数を追加することは、この設定はパフォーマンススキーマテーブル、または、
SHOW VARIABLESまたはSELECTステートメントを使用して表示できることを意味します。
・ALTER TABLEは、以下の条件が当てはまる時、（テーブルを再構築することなく）その場で列の
文字セットを変更するために使用できるようになりました。
* 列のデータ型はCHAR、VARCHAR、TEXT型、または、ENUMです。
* 文字セットの変更は、utf8mb3からutf8mb4、または任意の文字セットからバイナリへの変更です。
* 列にインデックスはありません。
・新しい-DFORCE_INSOURCE_BUILD CMakeオプションは、in-sourceビルドを強制するかどうかを
定義します。同じソースからの複数のビルドを許可し、ビルドディレクトリを削除することで
クリーンアップを迅速に実行できるため、out-of-sourceビルドをお勧めします。
in-sourceビルドを強制するためには、-DFORCE_INSOURCE_BUILD=ONを指定してCMakeを起動します。
■ 主なバグ修正
・重要な変更：MySQL 5.7サーバーからMySQL 8.0が動作するサーバーへのダンプのインポートは、 8.0サーバーでサポートされていないSQLモードが使用されていると、ER_WRONG_VALUE_FOR_VARで 失敗することがよくありました。これは、MySQL 5.7ではNO_AUTO_CREATE_USERがデフォルトで 有効になっていますが、MySQL 8.0ではサポートされていないため、頻繁に発生する可能性があります。 このような場合のサーバーの動作は、pseudo_slave_modeシステム変数の設定によって異なります。 これがfalseの場合、サーバーはER_UNSUPPORTED_SQL_MODEを使用してモード設定を拒否します。 pseudo_slave_modeがtrueの場合、サーバーはサポートされていないモードを無視して警告を出します。 mysqlbinlogがSQLを実行する前にpseudo_slave_modeをtrueに設定することに注意してください。 (Bug＃90337、Bug＃27828236) ・InnoDB：MySQLはSolaris X86で起動しませんでした。TempTableストレージエンジンの 静的スレッドローカルの'tables'変数が正しく初期化されませんでした。(Bug＃28987365) ・InnoDB：デッドロック検出中に使用されるラッチロジックが簡素化されました。(Bug＃28904966) ・InnoDB：古いバージョンのクラスタ化インデックスレコードに対する無効なレコードオフセットにより、 デバッグアサーションが発生しました。(Bug＃28825617) 参考：この問題は、Bug #25540277のレグレッションです。 ・InnoDB：履歴リストの長さがinnodb_max_purge_lagを超えた時の最小DML遅延が5000マイクロ秒から 5マイクロ秒に削減されました。(Bug＃28813453) ・InnoDB：あるスレッドが別の暗号化されたテーブルスペースを作成している間に別のスレッドが テーブルを削除しようとした時、不正確なロック順序がデッドロックを引き起こしました。 (Bug＃28774259) ・InnoDB：ALTER TABLESPACEは、サポートされていないテーブルスペース属性を無視できませんでした。 (Bug＃28656611) ・InnoDB：暗黙的から明示的へのロック変換ロジックが簡素化され最適化されました。(Bug＃28637472) ・InnoDB：フラグメントページの割り当て失敗によりアサーションが発生しました。(Bug＃28615893) ・InnoDB：誤って配置されたデバッグポイントのために、フラッシュされたLOBページが破損していると 見なされました。(Bug＃28607368) ・InnoDB：TempTableストレージエンジンは、tmpdir変数で定義されたディレクトリの代わりに、 システム一時ディレクトリに一時ファイルを誤って作成しました。(Bug＃28598943) ・InnoDB：全文検索の補助テーブルと同じ名前のテーブルを削除しようとすると、アサーション失敗が 発生しました。(Bug＃28577083) ・InnoDB：UPDATEクエリによって呼び出される関数が仮想列を考慮していませんでした。(Bug＃28560650) ・InnoDB：バッファプールのZIPハッシュのミューテックスに不正なキーが定義されていました。 (Bug＃28556539) ・InnoDB：mysql.innodb_table_statsテーブルとmysql.innodb_index_statsテーブルを含む バックグラウンドトランザクションのデッドロック処理が修正されました。これらのテーブルは、 内部テーブルがデッドロックサイクルに含まれる時にトリガーされるアサーションに誤って 含まれました。(Bug＃28523042、Bug＃92069) ・InnoDB：innodb_spin_wait_delayを高い値に設定すると、サーバーをシャットダウンしようとした時に アサーションの失敗が発生しました。この失敗が発生しないようにするために、 innodb_spin_wait_delayの最大値は1000に減らされました。(Bug＃28489407、Bug＃91973) ・InnoDB：外部キー制約とインデックス付き仮想列を持つテーブルに対するON DELETE CASCADE操作に より、サーバーが終了しました。(Bug＃28470805) ・InnoDB：仮想列の値を含む誤って書かれたDMLログがアサーションを起こしました。(Bug＃28448853) ・InnoDB：MySQLデータディレクトリの外部でDATA DIRECTORY句を使用して作成されたテーブルで RENAME TABLE操作を実行すると失敗しました。(Bug＃28341514) ・InnoDB：ALTER TABLE ... EXCHANGE PARTITIONは、異なる仮想列の定義を持つパーティションが 交換されることを許可しました。その結果、InnoDBが後で存在しない仮想列から読み込もうと した時にアサーションが発生しました。(Bug＃28235668) ・InnoDB：トランザクションのコミット中に発生したREDOログの書き込みリクエストと フラッシュリクエストのカウンタが追加されました。このカウンタは、連続したリクエスト間の 平均時間を計算するためにログライタースレッドによって使用されます。 平均時間が100マイクロ秒を超えると、ログライタースレッドはスピン遅延を使用せず、 代わりに10マイクロ秒のタイムアウト制限でリクエストイベントを待ちます。 ハングアップを引き起こす可能性があるログライタースレッドの実装の問題も修正されました。 (Bug＃28062382、Bug＃28444247、Bug＃28616442、Bug＃90890) ・InnoDB：完全に初期化されていない、新しく追加されたUNDOテーブルスペースに、 ロールバックセグメントを追加しようとするとアサーションが発生しました。(Bug＃27914054) ・InnoDB：RENAME TABLE操作後に外部キー制約が無視されました。(Bug＃27453180、Bug＃89441) ・InnoDB：O_DIRECT_NO_FSYNC innodb_flush_method設定を使用すると、ファイルシステムの メタデータが非同期になるためにシステムがハングアップする可能性があります。 この問題がO_DIRECT_NO_FSYNCモードで発生しないようにするために、 InnoDBは新しいファイルの作成後、ファイルサイズの拡大後、および、ファイルを閉じた後に、 fsync()を呼び出すようになりました。fsync()システムコールは各書き込み操作の後に まだスキップされます。 上記で説明された変更により、O_DIRECT_NO_FSYNCモードをEXT4およびXFSファイルシステムで安全に 使用できるようになりました。(Bug＃27309336) ・InnoDB：空の文字列を使用してCREATE TABLEまたはALTER TABLE ENCRYPTIONオプションを指定すると、 エラーは発生せず、ENCRYPTION= 'N'であるデフォルト設定として解釈されました。 空の文字列を指定すると、現在は無効として扱われ、エラーが発生します。(Bug＃27177845) ・InnoDB：Windows上のMySQLインスタンスからLinux上のlower_case_table_names変数が1に 設定されているMySQLインスタンスにテーブルスペースデータファイルを移動する時、 パーティションの接尾辞（パーティションテーブル名の#P#部分）が小文字に変換されませんでした。 テーブル名を完全に小文字に変換できなかったことによって、後でテーブル名を変更しようと した時にエラーが発生しました。(Bug＃26925260) ・InnoDB：64ビットのWindowsシステム上でサイズが4GBを超えるテーブルスペースファイルに書き込もうと すると、アサーションが発生しました。このエラーはナローイング変換が原因でした。 (Bug＃26636815、Bug＃87423) ・パーティショニング：破棄されたテーブルスペースに対して即時ADD COLUMNを実行しようとすると、 アサートが発生しました。現在、このような場合にはエラーが返されます。(Bug＃28517843) ・パーティショニング：BLOB列またはTEXT列を含む分割テーブルに対してALTER TABLEステートメントを 繰り返すと、正しく処理されないことがありました。(Bug＃28491099) ・パーティショニング：分割テーブルにDATA DIRECTORYオプションを使用した分割定義が1つ以上 ある場合、ALTER TABLE ... EXCHANGE PARTITIONは機能しませんでした。この修正は、 InnoDBストレージエンジンのみを使用している分割テーブルをサポートします。(Bug＃19730200) ・レプリケーション：group_replication_exit_state_actionの値によっては、グループから出る メンバーの動作は一致しませんでした。エラーシナリオに関係なくグループを終了するメンバーの動作を 同じにするために、現在は、group_replication_exit_state_action=READ_ONLYのメンバーが 意図せずにグループを出る時、メンバーが開始時に持っていたsuper_read_onlyモードが復元されます。 これにより、その動作は、group_replication_exit_state_action=ABORT_SERVERのメンバーの動作と 一致します。(Bug #28971639, Bug #28526591) ・レプリケーション：グループに新しいメンバーを追加する時、認証情報が大きすぎて送信することが できなかった場合、すべてのグループメンバーで失敗を引き起こすイベントが発生しました。 この状況を回避するために、現在は、認証情報が大きすぎる場合、参加メンバーをグループから 離脱させるエラーが発生します。(Bug #28900691, Bug #28443958) ・レプリケーション：group_replication_switch_to_multi_primary_modeや group_replication_set_as_primaryなどを使用して、グループがオンラインで再設定されている時、 メンバーを停止すると予期しない停止が発生する可能性がありました。現在、STOP GROUP_REPLICATIONを 発行する時、メンバーが再設定されているオンライングループの一部である場合、 グループコーディネータはグループレプリケーションが停止していることを知らされ、 メンバーはオンライン設定の完了を待ちます。(Bug #28807260) ・レプリケーション：CREATE TABLEステートメントのバイナリログに書き込まれるメタデータには、 テーブルの文字カラムの文字セット情報が含まれています。以前は、mysqlbinlogオプションの --print-table-metadataが指定されていると、デフォルトの文字セットがテーブルに 出力されていました。このデフォルトの文字セットは、テーブルの列に最も頻繁に現れる文字セットで あり、テーブルに指定されているデフォルトの文字セットと一致しない可能性があります。現在、 mysqlbinlogは各列の文字セットを個別に表示します。列も別々の行に表示されます。(Bug #28774144) ・レプリケーション：ENUMカラムおよびSET列のテーブルメタデータの一部として、文字セット情報は バイナリログに書き込まれませんでした。この情報は、現在、binlog_row_metadata=FULLが 設定されている時に追加され、拡張メタデータを生成します。（文字カラムの場合、 binlog_row_metadata=MINIMALを使用して、文字セット情報も追加されます。）(Bug #28706307) ・レプリケーション：レプリケーションを停止すると、トランザクションを保留していたチャネルが グループレプリケーションでデッドロックを引き起こす可能性があります。 (Bug #28636768, Bug #28365855) ・レプリケーション：バイナリログのROLLBACK TO SAVEPOINTステートメントの識別子の引用符の処理を 修正するためのパッチは、その後のMySQLバージョンには正しく適用されませんでした。 (Bug #28569645) ・レプリケーション：MySQL 5.7.23のパッチ適用後、その後のリリースで、LOAD DATAステートメントは MySQL 5.7.22のマスターからレプリケーションスレーブへのステートメントベースのレプリケーションを 停止しました。この問題は修正されました。(Bug #28541204, Bug #92132) ・レプリケーション：状況によっては、マスタ情報ログがテーブル（master_info_repository = TABLE） からファイル（master_info_repository = FILE）に変更された場合、 CHANGE MASTER TOステートメントをレプリケーションスレーブに対して使用できませんでした。 (Bug #28529558) ・レプリケーション：mysqlbinlogは、DML SQLステートメントを含むイベントに対して sql_require_primary_keyシステム変数（MySQL 8.0.13で導入された）をONに設定する ステートメントを誤って追加しました。システム変数がONに設定されているときに実行される チェックは、新しいテーブルを作成するか既存のテーブルの構造を変更する DDL SQLステートメントにのみ関係します。(Bug #28524803) ・レプリケーション：システム変数binlog_transaction_dependency_trackingおよび binlog_transaction_dependency_history_sizeを設定または読み込みした時、 必要なロックのタイプによっては、アクティブなバイナリログを処理するためにも同じロックが 必要とされたため、デッドロックシナリオが発生する可能性がありました。現在、代わりに 新しいロックタイプがトランザクション依存関係追跡システム変数へのアクセスに使用されるため、 このデッドロックは発生しません。(Bug #28511326, Bug #91941, Bug #28537209, Bug #92108) ・レプリケーション：次のトランザクションのGTID値が未定義（gtid_next=NOT_YET_DETERMINED）の時に 暗黙的なコミットを試みた場合、デバッグビルドでアサーションが発生しました。 gtid_nextシステム変数は、フォーマット記述イベントを実行するためにmysqlbinlogによって 内部使用ステートメントBINLOGが発行された直後にこの値を持ちます。暗黙的なコミットを含む ステートメント（CREATE TABLEステートメントなど）が次に試行された場合、gtid_next設定は AUTOMATIC状態に移行せず、受け入れられない状態のままでした。自動コミットがオンの場合、 ステートメントの試行時にエラーER_CANT_SET_GTID_NEXT_TO_ANONYMOUS_WHEN_GTID_MODE_IS_ONも 記録されました。 この問題を解決するために、現在、gtid_nextの状態が変更された場合、トランザクション中に BINLOGステートメントを使用できません。これを試みると、 エラーER_VARIABLE_NOT_SETTABLE_IN_TRANSACTIONが返されます。また、GTIDが使用され、 gtid_nextの値がNOT_YET_DETERMINEDの場合、次のステートメントはgtid_nextを明示的に 有効な値に設定するか、GTID状態を影響を受けないままにしておく必要があります。 そうでない場合は、エラーER_CANT_SET_GTID_NEXT_TO_ANONYMOUS_WHEN_GTID_MODE_IS_ONが 返されます。(Bug #28490793, Bug #91980) ・レプリケーション：group_replication_exit_state_actionがABORT_SERVERに設定されている時、 グループレプリケーションのプラグインはWL#12003によって追加された新しいコンポーネントサービスを 使用してMySQLをシャットダウンするようになりました。(Bug #28401703) ・レプリケーション：group_replication_switch_to_single_primary_mode()を使用した時、 非同期チャネルを持つメンバーでエラーが発生した場合、非同期レプリケーションチャネルは 正しく停止されず、サーバーが突然停止することがありました。(Bug #28382590) ・レプリケーション：PURGE BINARY LOGS TO 'log_name'ステートメントは、 mysqlbinlogmoveを使用して別の場所に移動されたバイナリログファイルに対して、 失敗しました。そのようなファイルは、バイナリログインデックスファイルに今もリストされていますが、 バイナリログファイルが通常保存されているディレクトリとの相対パスではなく、絶対パスを使用して リストされています。MySQL Serverは、現在、移動したバイナリログファイルを正常に検索して 削除できます。(Bug #28284624) ・レプリケーション：メンバーがUNREACHABLEまたはRECOVERING状態の間は、 group_replication_switch_to_single_primary_modeなど、 グループを構成するグループコーディネーターベースのUDFを使用することができ、 これにより、すべてのメンバーがオンラインになるまで操作が待機しました。 この結果、グループコーディネーター操作が正常に完了しない可能性がありました。 現在、この状態のグループに対してこれらのUDFのいずれかを発行すると、エラーが返されます。 UDFを使用してグループを設定しようとする前に、すべてのメンバーがオンラインに なっていることを確認してください。(Bug #28284355) ・レプリケーション：binlog_formatがMIXEDに設定されている場合、関数に一時テーブルに適用される DMLステートメントとDROP TEMPORARY TABLEステートメントが含まれていると、その関数呼び出しは バイナリログに書き込まれず、レプリケーションエラーを発生させました。現在、 関数に一時テーブルを操作するDMLステートメントが含まれる場合、関数呼び出しは MIXEDレプリケーションモードでバイナリログに書き込まれるようになりました。 (Bug #28258992) ・レプリケーション：GTIDが使用されていてsuper_read_only=ONが設定されている レプリケーションスレーブまたはグループレプリケーションのグループメンバーに対して autocommitが0に設定されている場合、サーバーのシャットダウンは完了しなかった トランザクションによって妨げられました。トランザクションはGTIDを mysql.gtid_executedテーブルに保存しようとしましたが、super_read_only=ONが 設定されているため、更新は失敗しました。（autocommitを1に設定すると、この状況で トランザクションは完了し、代わりにmysql.gtid_executedテーブルはサーバーの起動時に 更新されます。）現在、super_read_only設定のチェックはこのタスクでスキップされるので、 トランザクションはGTIDをmysql.gtid_executedテーブルに保存し、super_read_onlyと autocommitの設定の組み合わせに関係なく完了します。(Bug #28183718) ・レプリケーション：gtid_nextの値が手動で設定された時に、未知のトランザクション識別子に対して XA ROLLBACKステートメントが発行された場合、デバッグビルドでアサーションが発生しました。 現在、XA ROLLBACKステートメントがエラーで失敗した場合、サーバーはGTID状態を更新しようと しません。(Bug #27928837, Bug #90640) ・レプリケーション：トランザクションがコミットまたはロールバックされた直後に SELECT... FOR UPDATEステートメントが発行され、そのトランザクションが gtid_nextセッションシステム変数を使用して手動でGTIDを割り当てられた場合、 デバッグビルドでアサーションが発生しました。gtid_nextがトランザクションのGTIDを 設定するために使用され、そのトランザクションがコミットまたはロールバックされた後、 別の明示的なSET GTID_NEXTステートメントが他のステートメントの前に発行されなければ なりません。それ以外の場合、gtid_next値は未定義のままです。 SELECT ... FOR UPDATEステートメントは、書き込みロックを取得したため、この状況では GTID整合性違反を引き起こしましたが、変更は加えませんでした。現在、書き込みロックを 取得するSELECT ... FOR UPDATEステートメントは、この状況ではエラーを返します。 (Bug #27903848, Bug #90547) ・レプリケーション：負荷が大きい場合、バイナリロググループコミットの競合状態によってサーバーが 突然停止する可能性がありました。この状況を防ぐために、トランザクションコミットの追跡が 変更されました。(Bug #27556117) ・レプリケーション：既存のすべてのリレーログファイルの合計サイズ（Relay_Log_Space）に対して SHOW SLAVE STATUSステートメントで返される値は、リレーログファイルが使用する実際の ディスク容量よりもはるかに大きくなる可能性があります。I/Oスレッドは、値を更新している間、 変数をロックしなかったので、SQLスレッドは、I/Oスレッドが値の更新を終了する前に、 リレーログファイルを自動的に削除し、減少した値を書き込む可能性があります。その後、 I/Oスレッドは、SQLスレッドの更新を無視し、削除されたファイルのスペースを戻して追加して、 元のサイズ計算を書き込みます。現在、同時更新を防ぎ、正確な計算を保証するために、 Relay_Log_Space値は更新中ロックされます。(Bug #26997096, Bug #87832) ・レプリケーション：レプリケーションスレーブのバックアッププロセスによって リレーログインデックスファイルが一時的に表示用にロックされており、MySQLサーバーが その時点で名前変更または削除操作のためにファイルにアクセスしようとした場合、 バックアップは警告付きで完了しましたが、MySQLサーバーは予期しない停止を経験しました。 現在、MySQLサーバーは、これまたは類似のシナリオが原因で、ファイルが間もなく 再び使用可能になる場合に、ファイルアクセス操作を何度も再試行します。(Bug #25839610) ・レプリケーション：sync_binlog=1が設定されている時、バイナリログがバイナリログの終了位置が 更新される前にコミット中にローテーションされた場合、サーバーは新しいバイナリログファイルで 古いバイナリログの終了位置を使用しようとしたために、レプリケーションはスレーブで停止しました。 現在、サーバーは、バイナリログの終了位置を更新する時に、バイナリログファイル名と アクティブなバイナリログファイルを比較するので、その問題は発生しません。 (Bug #22252394, Bug #25524203, Bug #84752) ・レプリケーション：一定のピーク負荷を持つグループにメンバーが参加すると、そのメンバーは RECOVERINGからONLINE状態に移行できない可能性があります。その原因は、 * メンバーは、新しいトランザクションがさらに到着しているのに、リカバリー中に到着した トランザクションの完全なキューが適用されるのをループで待っていました。 * 完全なキューが適用された時でも、メンバーはアプライヤが一時停止されていることを 確認していました。これは、継続的なピークワークロードで発生する可能性は低いです。 現在、リカバリー完了ポリシーがトランザクションの適用を待っている時、メンバーはまず 以下の条件のいずれかが満たされるまで待機します。 * 適用するトランザクションはフロー制御設定内に収まります。つまり、適用される トランザクションは、次のフロー制御の繰り返し中に適用されることが可能です。 * リカバリーキューが空の場合、トランザクションはキューに入れられたり適用されたりしません。 それから、メンバーは、メンバーの状態がONLINEに変わる前に、group_replication_applierチャネルで 現在キューに入れられているトランザクションが適用されるのを待ちます。 (Bug＃89582、Bug＃27511404) ・Microsoft Windows：既存のMySQLサービスの削除に失敗した後、MySQLインストーラーが失敗することが ありました。現在、これは致命的ではないものとして扱われるため、インストール操作は 続行できますが、サービスのクリーンアップを許可するにはシステムの再起動が必要になる場合が あります。(Bug #29016677, Bug #93048) ・Microsoft Windows：同じユーザーに対して同じホスト上でmysqldの複数インスタンスが --no-monitorオプションを使用して起動された場合、SHUTDOWNコマンドが誤ったサーバプロセスを シャットダウンしました。この修正では、プロセスのプロセスIDを追加することによって、 --no-monitorで使用するための一意のシャットダウンイベント名を作成するようになりました。 (Bug #28723675) ・X DevAPI：Xプロトコルを使用している時、OUT変数としてユーザ変数を指定して呼び出した ストアドプロシージャはその変数の値を設定しませんでした。(Bug #91907, Bug #28458752) ・JSON：JSONオブジェクトを繰り返し処理した結果、不要な文字列の割り当てが発生しました。 (Bug #28975640) ・JSON：JSON値をテキストに変換すると変換先文字列の長さが増加し、不必要に多数の再割り当てが 発生しました。現在、このプロセスは代わりに指数的成長を使用して、必要な割り当て数を 減らします。(Bug #28949700) ・JSON：YEARの値はJSONに不透明なデータとして保存されました。YEAR値を含むJSONドキュメントが テキストに変換されると、YEAR値はbase64でエンコードされた文字列として表示されました。 この問題を解決するために、現在YEAR値は符号なし整数として保存されます。これにより、 テキストに変換されると、数値として表示されます。この修正の追加の利点は、 JSONドキュメント内のYEAR値に必要なストレージ容量が少なくなったことです。(Bug #28947107) ・JSON：JSON列を含むARCHIVEテーブルに対してUPDATEまたはDELETEを実行しようとすると アサートします。(Bug #28923281) ・JSON：FEDERATEDテーブルのJSON列から選択しようとした時、ER_INVALID_JSON_PATH_CHARSETを 返したサーバーはCHARACTER SET 'binary'の文字列からJSON値を作成できません。 さらに、DELETEもUPDATEも、JSON列を含むFEDERATEDテーブルには影響しませんでした。 (Bug #28877215) ・JSON：SELECT jt.* FROM t1, JSON_TABLE(t1.c, '$[*]' COLUMNS (num INT PATH '$[0]')) AS jt の形式のクエリは、クエリを実行しているユーザーが列cに対するSELECT権限持っていても、 パーミッションエラーのために失敗しました。(Bug #23254268) ・Bug #27855592によって実装された機能に対してFacebookが提供したコードが更新されました。 (Bug #28950397) 参考：Bug #27855592。 ・SuSE Linuxでは、pthread_mutex_destroy()からの誤ったEBUSY戻り値は処理されませんでした。 (Bug #28948462) ・mysqld_safeとmysqld_multiがクライアント専用パッケージに誤って含まれていました。 (Bug #28942508) ・ホストキャッシュのロック処理のミスによって、サーバーが終了する可能性がありました。 (Bug #28936159) ・audit_logプラグインがインストールされている場合、MySQL Enterprise Firewallは うまく機能しませんでした。(Bug #28930885、Bug #93184) ・Windows上のVisual Studioで正常にビルドできるように修正が行われました。 (Bug #28892711、Bug #93077) ・以前は、COMPILATION_COMMENT CMakeオプションは、サーバー（例えば、version_comment システム変数を設定するために)や他のプログラムによって使用されていました。 しかしながら、値に"server"という単語が含まれていた場合、他のプログラムによる使用には 適していませんでした。現在、サーバーは新しいCOMPILATION_COMMENT_SERVERオプションを 使用します。他のプログラムはCOMPILATION_COMMENTを使用し続けます。(Bug #28888510) ・mysqld_multiが正しいdatadir値をmysqldに渡すことに失敗することがありました。 (Bug #28866662、Bug #90801) ・マルチバイト文字を含むスキーマ名に遭遇した時、ルーチン、イベント、およびトリガの MDLキー作成中にパラメータスキーマ名をチェックして名前が小文字であることを確認する デバッグアサーションが失敗しました。(Bug #28864244) ・エラーメッセージのフォーマット指定子が誤った数値を表示しないように改善されました。 (Bug #28860795) ・Windows上でのデバッグビルドでは、未使用のメモリリークチェックが有効になっており、 シャットダウン処理が遅くなる可能性がありました。 現在、これらのチェックは特殊なビルドに対してのみ有効です。(Bug #28857626) ・sql_require_primary_keyシステム変数が有効になっている場合、mysql_upgradeは特定の システムテーブルのアップグレードに失敗することがありました。(Bug #28855207、Bug #92988) ・-DWITH_LIBWRAP=ONを使用して設定されたビルドはコンパイルしませんでした。 (Bug #28853650、Bug #92983) ・InnoDBテーブルでは、DEFAULT()関数で参照される列のデフォルトが列をNULL可能にすることで 変更された場合、DEFAULT()関数に依存するストアドまたはインデックス付き仮想生成列の値は ALTER TABLEで正しく更新されませんでした。(Bug #28848265) ・/permissiveフラグをオンにして、Windows上のVisual Studioで正常にビルドできるように修正が 行われました。(Bug #28842878、Bug #92943) ・-DCMAKE_BUILD_TYPE=Releaseを使用して設定されたビルドはコンパイルしませんでした。 (Bug #28841366、Bug #92945) ・ALTER TABLEは、現在、以下の条件に該当する場合にINPLACEアルゴリズムを使用できます。 * InnoDBテーブルの場合、生成されたストアドカラムを変更するが、そのタイプ、式、または、 null許容かどうかを変更しないステートメント。 * InnoDB以外のテーブルの場合、生成されたストアドカラムまたは仮想カラムを変更するが、 そのタイプ、式、または、NULL許容かどうかを変更しないステートメント。 そのような変更の例は、カラムのコメントへの変更です。(Bug #28836543) ・プラグインが再インストールされる時、永続化されていたプラグインシステム変数が 適用されませんでした。(Bug #28823972) ・EXPLAIN ... FOR CONNECTIONは別の接続のSQLモードを変更する可能性がありました。 (Bug #28786981) ・サーバーがREDOログファイルと同じ名前のデータベースの作成を許可したため、予期しないサーバ動作が 発生する可能性があります。このような名前はデータベース名としては許可されなくなりました。 (Bug #28867993) ・別のlibtirpcライブラリにするため、glibcからSun RPC and XDRを削除したため、 プラットフォームによってはlibasanで問題が発生しました。 (Bug #28785835、Bug #92762、Bug #28897799、Bug #93116) ・カラムbにインデックスがあり、SELECT a FROM table WHERE b = valueという形式のクエリの 処理中に2つのENUM値を比較するとアサートする可能性がありました。(Bug #28769996) ・offline_modeシステム変数への読み書きアクセスを同時に行うと、デッドロックが発生する 可能性がありました。(Bug #28761869) ・MySQL 5.7からMySQL 8.0へのアップグレード時にトリガーが誤った順序でメモリにロードされ、 アサーションの失敗が引き起こされました。(Bug #28760011, Bug #92609) ・パフォーマンススキーマのdata_locksテーブルを含むJOINは、誤った結果を生成する可能性が ありました。(Bug #28733170) ・スカラサブクエリを使用した多重ネストサブクエリの中には、正しく処理されないものが ありました。(Bug #28723670) ・Ubuntuでは、インストールされた/etc/mysql/mysql.conf.d/default-auth-override.cnfファイルが 誤って実行モードで作成されました。(Bug #28714840, Bug #92587) ・メモリリークは、同じユーザーレベルのロックを保持している同時接続が原因で失敗した ゼロタイムアウトでのGET_LOCK()の呼び出しによって引き起こされました。(Bug #28714367) ・大量のテーブルをホストするサーバーが起動と停止を繰り返すと、ヒープの破壊やサーバーの終了が 発生する可能性がありました。(Bug＃28705511) ・MySQLルーターがMySQLサーバーのMSIパッケージから消えていました。(Bug＃28685556) ・ストアドファンクションGTID_SUBTRACT_UUIDの例は、記載されたバージョンと一致するように コードを修正しました。(Bug＃28670170) ・CAP_SYS_NICE機能は、Linux用のMySQLパッケージインストーラーによってmysqldに対して有効では なくなりました。（これは、リソースグループのスレッド優先順位の使用を容易にするために 行われました。）スレッド優先順位へのアクセスを必要とするLinuxデプロイメントの場合、 リソースグループ制限でCAP_SYS_NICE機能を有効にするためのMySQLリファレンスマニュアルの 指示を参照してください。(Bug＃28670160) ・<=>演算子の内部実装を簡素化しました。(Bug＃28660232) ・グループからサーバーインスタンスを削除するためにSTOP GROUP_REPLICATIONステートメントが 発行された後、"[GCS] Error pushing message into group communication engine"という エラーメッセージの複数インスタンスがサーバーに記録されました。現在、サーバーが グループから脱退する過程にある時、または、サーバーがグループのメンバーではなくなった時、 エラーは無視されます。(Bug＃28658228、Bug＃92454) ・疑わしいグループレプリケーションのグループメンバーを削除する前の待ち時間の最大タイムアウト 設定が3600秒（1時間）に短縮されました。以前は、group_replication_member_expel_timeout システム変数は最大31536000秒の値に設定できました。新しい上限は、グループから 非アクティブメンバーを削除するためのより合理的な最大値を提供します。タイムアウトの デフォルト設定はゼロです。これは、5秒の検出期間が終了した直後に非アクティブなメンバーは 削除の義務があることを意味します。タイムアウト値を指定することは、遅いネットワークでの 不要な削除を防ぐために、または、一時的なネットワーク障害やマシンのスローダウンが 予想される場合に、有用です。(Bug＃28656750) ・あるカラムのCHARACTER SET属性がJSON_TABLE(... COLUMNS ...)で暗黙的に設定されていた場合、 結果として生じるカラムはデフォルトのキャラクタセットとしてグローバルのcharacter_set_results を使用しました。現在、このカラムは、セッションのcharacter_set_connectionと collation_connectionの値を使用します。(Bug＃28643862) ・行の値を生成した式に関数インデックスを追加するとアサーションが発生しました。現在は、 その代わりにエラーが発生します。(Bug＃28643252) ・デバッグビルドで、sql-modeをTIME_TRUNCATE_FRACTIONALに設定した後にトリガを作成すると アサーションの失敗が引き起こされました。SQLモードが、 mysql.triggersデータディクショナリテーブルのsql_modeカラムに存在しませんでした。 (Bug＃28642918) ・--log-timestamps=SYSTEMの使用時、ログメッセージのISO 8601タイムスタンプは夏時間を 考慮していませんでした。 （Bug＃28632725） ・エラーER_IB_MSG_720の引数が正しく計算されていませんでした。 （Bug＃28629175） ・ソケットファイルを指定するためのオプションが正しく指定されていない場合、サーバーは 起動時に終了する可能性がありました。 （Bug＃28609181） ・子テーブルとは異なるストレージエンジンを持つ親テーブルを追加してから、親テーブルを その子テーブルと同じストレージエンジンに変更することによって、矛盾する外部キーを 作成することが可能でした。 （Bug＃28608460、Bug＃92317） ・サーバーがレプリケーショングループに参加している時、group_replication_group_seeds システム変数にリストされている最初のシードメンバーに接続しようとします。接続が 拒否された場合、参加メンバーはリスト内の他の各シードメンバーに順番に接続しようとします。 以前は、参加メンバーがシードメンバーに接続しても、結果としてレプリケーショングループに 追加されなかった場合、参加メンバーはそれ以上接続を試みませんでした。この状況は、 接続後にシードメンバーが失敗した場合、または、シードメンバーのホワイトリストに 参加メンバーのアドレスがなくて接続を閉じた場合、または、シードメンバーが参加メンバーの グループ参加リクエストを拒否した場合に、発生する可能性がありました。現在は、 参加メンバーがシードメンバーに接続してもグループに参加できなかった場合、参加メンバーは 順番にリスト内の残りのシードメンバーを試し続けます。 （Bug＃28602835） ・割り当ての特定のパターン、アロケーターの再バインドを伴うコピー、割り当て解除を考えると、 temptable::Allocatorは解放されたメモリブロックを再利用することが可能でした。これは、 Windowsプラットフォーム上のテストスイートでの障害の原因となりました。 （Bug＃28595557） ・ルーチンやビューを変更する時に、time_zoneを負のオフセットに設定し、timestampを低い値に 設定すると、アサーションが発生しました。 （Bug＃28590623、Bug＃92273） ・pid_fileシステム変数をDEFAULTにしておくと、次のサーバー起動時にNULLの値になる可能性が ありました。 （Bug＃28589736） ・誤った権限チェックによって、MySQL 5.7では正常に実行されていたSELECT ... FOR UPDATE ステートメントに対してエラーが発生する可能性がありました。 （Bug＃28581664、Bug＃92254） ・ALTER TABLEを使用して外部キーの親カラムの名前を変更しようとすると失敗する可能性が ありました。 （Bug＃28581468） ・RESET PERSISTの権限が正しくチェックされませんでした。 （Bug＃28564239） ・AVG(YEAR(datetime_column))の計算時にオーバーフローが発生しました。 （Bug＃28562930） ・サーバーの再起動後、パフォーマンススキーマのvariables_infoテーブルの永続化システム変数の パス名が誤って計算される可能性がありました。 （Bug＃28561584） ・分割テーブルの名前のチェックで無効なアサーションが発生しました。 （Bug＃28556942） ・handler::create()関数が条件リストのエラーで呼び出される可能性がありました。これによって、 handler::create()関数のエラーが適切に報告されない可能性がありました。 （Bug＃28556264） ・ALTER TABLEの場合、ALGORITHM=INSTANTはMySQL 8.0.12より前のバージョンで作成されたテーブルで 誤って拒否されました。 （Bug＃28554157、Bug＃92194） ・JSON_TABLE()関数のCOLUMNS句のデータ型でCOLLATE属性が拒否されました。(Bug＃28538315) ・符号付きの値を持つプラグイン変数が正しく表示されませんでした。(Bug＃28534414、Bug＃92107) ・Event_queue::lock_dataとSAFE_MUTEXの実装でThread Sanitizerによって発見されたデータ競合が 修正されました。(Bug＃28510721、Bug＃92041、Bug＃28510691、Bug＃92040) ・準備済みステートメントの再準備が失敗した時、ER_NEED_REPREPARE診断が診断領域にプッシュ されませんでした。(Bug＃28509306、Bug＃92029) ・WITH ROLLUPを使用して式を評価する時、現在は、一時テーブルカラムを持つ場合にのみ式の結果を 一時テーブルに書き込みます。(Bug＃28493849、Bug＃28523014) ・デバッグビルドの場合、TEMPORARYテーブルのALTER TABLEに対する誤った外部キーエラーチェックは サーバーを終了させる可能性がありました。(Bug＃28493257、Bug＃91990) ・一部のシステム変数では、SET PERSISTは指定された値ではなくデフォルト値を保持しました。 (Bug＃28466045) ・SET RESOURCE GROUPは準備済みステートメントとして実行されないことがありました。 (Bug＃28448258、Bug＃91876) ・ウィンドウ関数を実装するために行われた作業中に誤って削除されたItem_field::fix_fields()への 呼び出しを復元しました。(Bug＃28431783) ・Xプラグインの起動中およびシャットダウン中にThread Sanitizerによって報告されたデータ競合が 修正されました。(Bug＃28407294) ・不正なutf8文字を含むパーティションの説明を持つテーブルを作成すると、アサーションが 発生しました。(Bug＃28387488、Bug＃91763) ・mysqldumpの出力には、削除されたSQLモードの値が含まれている可能性がありました。 (Bug＃28373001、Bug＃91714) ・潜在的なロック順序サイクルが修正されました。(Bug＃28366531) ・テーブル定義にutf32テーブルキャラクターセットとリテラル文字列を持つテーブルに関する CREATE TABLEステートメントでアサーションが発生しました。(Bug＃28275881) ・サーバーのアップグレードが正常に完了した時のサーバーのバージョン番号の更新をサポートするための 内部機能が追加されました。(Bug＃28211486) ・mysqlpumpは、エラーが発生した時にすべての割り当てられたリソースを解放しなかったため、 メモリリークが発生しました。(Bug #28538971、Bug #92131) ・デバッグビルドの場合、CREATE USERステートメントをロールバックしようとするとサーバーが 終了することがありました。(Bug #28536312) ・廃止予定のシステム変数を誤って処理すると、パフォーマンススキーマのvariables_by_threadテーブル に対するクエリからの出力が正しくなくなる可能性があります。(Bug #28515475、Bug #92049) ・GTID対応サーバーでは、INFORMATION_SCHEMA.COLUMNSテーブルに対する同時ステートメントが デッドロックすることがありました。(Bug #28293047, Bug #91548) ・memcmp()関数を使用して文字列としてログファイル名を比較すると、初期化されていない メモリ読み取りエラーが発生しました。現在、この比較はstrncmp()関数を使用します。 (Bug #28178776, Bug #90238) ・複合インデックスの2番目の列に対してLIKE句を使用したINNER JOINを実行した時、オプティマイザーは その2番目の列をスキップしました。(Bug #28086754) ・CREATE TABLE ... SELECTは、デフォルト値なしで作成したはずの日付列をデフォルト値"ゼロ"日で 作成することがありました。(Bug #28022129) ・INサブクエリ述部のセミジョインへの変換は、非常に多くのテーブルで正しく処理されませんでした。 (Bug #28004674) ・サーバーがSIGHUP信号を誤って処理すると、サーバーが終了する可能性があります。 (Bug #27966483, Bug #90742) ・アカウント管理ステートメントによる不適切なメモリー処理は、サーバーの誤動作の原因となる可能性が あります。(Bug #27820277) ・多数のプレースホルダーを持つ複数行の挿入を実行するために準備済みステートメントを実行すると、 過剰なメモリーが消費され、実行が遅くなる可能性がありました。(Bug #27703912) ・パーサーは、サーバーが終了する可能性のあるトリガー定義内の無効なSETステートメント構文を 受け入れました。(Bug #27595603) ・keyring_encrypted_fileプラグインキーリングファイルが無効な場合、サーバーは 起動できませんでした。(Bug #27588064) ・CURSOR_TYPE_READ_ONLYフラグを設定したプロシージャー呼び出しで準備済みステートメントを 実行する時、プロシージャーが空の結果セットを返すSELECTを実行した場合、 クライアントライブラリーはハングしました。(Bug #27443252、Bug #89214) ・パーサーは、いくつかのメモリー不足チェックを誤って実行しました。(Bug #25633994) ・IGNOREを使用したDMLステートメントは、生成された列を持つテーブルで常に正しく 処理されませんでした。(Bug #22990029) ・ダイナミックレンジとインデックスマージを使用するクエリは、予想よりも多くのメモリを使用する 可能性があります。(Bug #89953, Bug #27659490)
全ての変更点やバグ修正については、以下のページをご覧ください。
MySQL 8.0.14リリースノート（MySQLウェブサイト）： http://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-14.html
MySQL Editions
MySQLのサブスクリプションは、24時間365日体制でお客様をサポートいたします。さらに MySQL Enterprise Edition では、データベース管理者支援ツール MySQL Enterprise Monitor やバックアップツール MySQL Enterprise Backup をご利用いただけます。