主な変更点
■ アカウント管理関連
・アカウントパスワードを変更しようとすると、置き換えられる現在のパスワードを指定することによって 認証されることを要求できるようになりました。これにより、DBAは、ユーザーが現在のパスワードを 知っていることを証明せずにパスワードを変更できないようにすることができます。 password_require_currentシステム変数を使用して、および、CREATE USERステートメントと ALTER USERステートメントのPASSWORD REQUIREオプションを使用したアカウント単位で、 グローバルにパスワード認証ポリシーを確立することが可能です。既存のパスワード管理機能と併せて、 認証を要求する新しい機能により、DBAはパスワード管理をより完全に制御できます。 ＜重要＞ MySQLは、mysql.userシステムテーブルの新しい列を使用したパスワード認証機能を実装しています。 旧バージョンのMySQLからこのリリースにアップグレードする場合、このシステムデータベースの変更 を組み込むために、mysql_upgradeを実行する（そして、サーバーを再起動する）必要があります。 これが完了するまで、パスワードの変更はできません。
■ コンパイル関連
・Solaris: MySQLは、gccを使用してSolaris上でコンパイルされることが可能になりました。 (Bug #27802681)
■ 設定関連
・新しいWITH_LTO CMakeオプションは、リンク時の最適化を有効にするかどうかを制御します。 現在、これはGCC 7と8でのみサポートされています。(Bug #28184537, Bug #28211382) ・新しいWITH_RAPIDJSON CMakeオプションは、バンドルされたRapidJSONライブラリまたは システムRapidJSONライブラリを使用してコンパイルするかどうかを制御します。 (Bug #28024992, Bug #90867) ・CMAKE_BUILD_TYPE CMakeオプションは、リリースビルドタイプをサポートするように なりました。これは、RelWithDebInfoビルドタイプと似ていますが、ビルドサイズを 減らすためのデバッグ情報を省略します。(Bug #27874068) ・新しいsql_require_primary_keyシステム変数を使用すると、新しいテーブルを作成するか 既存のテーブルの構造を変更するステートメントにテーブルにプライマリーキーがあるという 要件を強制させることができます。この変数を有効にすると、テーブルにプライマリーキーが ない場合に発生し得る行ベースのレプリケーションでのパフォーマンスの問題を回避できます。 テーブルにプライマリーキーがなく、更新または削除によって複数の行が変更されたとします。 マスターサーバーでは、この操作は単一のテーブルスキャンを使用して実行できますが、 行ベースのレプリケーションを使用してレプリケートすると、スレーブ上で変更される各行の テーブルスキャンが行われます。プライマリーキーがある場合、これらのテーブルスキャンは 発生しません。(Bug＃17468242、Bug＃69845、Bug＃17005592、Bug＃69223) ・サーバーが一連のアドレスでリッスンできるようにするために、--bind-addressオプションは、 単一のアドレスまたは名前だけでなく、コンマで区切られたIPアドレスまたはホスト名の リストを許可するようになりました。
■ データタイプ関連
・MySQLはデータ型の仕様でデフォルト値としての式の使用をサポートするようになりました。 これには、BLOBやTEXT、GEOMETRY、JSONのデータ型のデフォルト値としての式の使用が 含まれます。これらには、以前はデフォルト値を割り当てることができませんでした。
■ 廃止予定と削除
・InnoDB; パーティショニング: 共有テーブルスペースへのテーブルパーティションの配置の サポートは削除されました。共有テーブルスペースには、システムテーブルスペースと 一般的なテーブルスペースが含まれます。 ・InnoDB: CREATE TEMPORARY TABLEと共に使用されるTABLESPACE = innodb_file_per_table およびTABLESPACE = innodb_temporary句のサポートは廃止予定で、 MySQLの将来のバージョンで削除されます。 ・utf8mb3キャラクターセットは廃止予定で、MySQLの将来のバージョンで削除されます。 代わりにutf8mb4を使用してください。 ・ネストされたコメントは、（いくつかの条件の下では許可される可能性がありますが） サポートされたことはありません。 現在は非推奨とみなされており、将来のMySQLリリースで削除されます。 ・廃止予定だったシステム変数metadata_locks_cache_sizeとmetadata_locks_hash_instances は削除されました。 ・PAD_CHAR_TO_FULL_LENGTHのSQLモードは非推奨であり、MySQLの将来のバージョンで 削除されます。
■ エラー処理
・MySQLクライアントライブラリは、OpenSSLエラーに関して、より良いエラーメッセージを 返すようになりました。(Bug #27855668, Bug #90418) ・以前は、ユーザーが親テーブルへのアクセス権限を持たない場合でも、外部キー操作に関する エラーメッセージであるER_NO_REFERENCED_ROW_2とER_ROW_IS_REFERENCED_2が表示され、 親テーブルに関する情報が明らかになりました。この状況に関するエラー操作は修正されました。 * ユーザーがすべての親テーブルに対するテーブルレベルの権限を持つ場合、 以前と同様に、ER_NO_REFERENCED_ROW_2とER_ROW_IS_REFERENCED_2は表示されます。 * ユーザーがすべての親テーブルに対するテーブルレベルの権限を持たない場合、 ER_NO_REFERENCED_ROW_2とER_ROW_IS_REFERENCED_2の代わりに、 より一般的なエラーメッセージが表示されます。 例外として、DEFINER権限で実行するように定義されたストアドプログラムについて、 権限が評価されるユーザーはプログラムのDEFINER句のユーザーであり、呼び出すユーザーでは ありません。そのユーザーがテーブルレベルの親テーブルの権限を持つ場合、親テーブルの情報は まだ表示されます。この場合、適切な条件ハンドラを含むことによって情報を隠すことは、 ストアドプログラムの作成者の義務です。(Bug #19477611)
■ INFORMATION_SCHEMA関連
・これらの新しいINFORMATION_SCHEMAテーブルは、データディクショナリテーブルのビューとして 使用できます。 * VIEW_ROUTINE_USAGEは、ビューの定義で使用されるストアドファンクションに関する情報を 提供します。 * VIEW_TABLE_USAGEは、ビューの定義で使用されるテーブルとビューに関する情報を提供します。
■ ロギング関連
・互換性のない変更: 以前はシステムログ（WindowsのEvent Log、および、UnixとUnixのような システムのsyslog）にエラーをロギングするよう設定されていたシステム変数が削除されました。 必要に応じて、削除されたシステム変数は、log_sink_syseventlogエラーログコンポーネントに よって管理される新しいシステム変数に置き換えられました。古い変数名と新しい変数名は 以下のとおりです。 Old System Variable - New System Variable log_syslog_facility - syseventlog.facility log_syslog_include_pid - syseventlog.include_pid log_syslog_tag - syseventlog.tag log_syslog - None ＜重要＞ 古いシステム変数名を使用したインストールは、新しい変数を使用するために設定を 更新しなければなりません。 参照: 関連項目: Bug #27534089。 ・新しいシステム変数のlog_error_suppression_listを使用すると、重大度がWARNINGまたは INFORMATIONの診断が発生した時に、どの診断をエラーログに書き込まないかを指定することが できます。例えば、特定の種類の警告が頻繁に発生するが、興味がない （そして、エラーログで望ましくない“ノイズ”とみなされるかもしれない）場合、 現在はそれを抑制することができます。 ・アカウント管理ステートメントの再書き込みを処理するコードは、より簡単に維持拡張できるように リファクタリングされました。この結果、監査ログや一般ログ、スロークエリログにユーザーの 目に見える小さな影響がいくつかありました。 * プレーンテキストのパスワードは、'<string>'ではなく<string>に置き換えられます。 * デフォルト句は、ユーザーによって指定されない限り書き込まれません。 ・以前、様々な内部サーバーメソッドによってエラーログに書き込まれたメッセージは、 ER_LOG_PRINTF_MSGエラーログを使用して記録されました。これらのメッセージはそれぞれ、 一意のエラーコードを使用して記録されるようになりました。
■ オプティマイザ関連
・オプティマイザは、クエリパフォーマンスを改善するために、範囲アクセスを以前には 適用できない状況で使用できるようにするスキップスキャンアクセスメソッドを サポートするようになりました。(Bug #26976512, Bug #88103) ・MySQLは、カラム値ではなく式の値をインデックスする式インデックスの作成をサポートする ようになりました。式インデックスは、例えばJSON値など、他の方法ではインデックスする ことができない値のインデックス化を有効にします。 ・InnoDBテーブルのSELECT COUNT(*) FROM tbl_nameクエリのパフォーマンスは、 シングルスレッドのワークロードや、WHEREまたはGROUP BYなどの余分な句が使用されていない 場合について、改善されました。
■ パッケージング関連
・システムcurlライブラリへのリンクではなくcurlを含むバイナリパッケージは、 現在curl 7.45.0ではなくcurl 7.60.0を使用します。(Bug #28043702) ・Debianのパッケージングは、yaSSLの削除を反映するように更新され、すべてのビルドに関して OpenSSLがデフォルトSSLライブラリです。(Bug #28025599) ・テストプラグインは、サーバーパッケージからテストパッケージに移動されました。 (Bug #27860172) ・MySQLルーターは、現在、MySQLサーバーソースとモノリシックバイナリパッケージに含まれます。
■ パフォーマンススキーマ関連
・ハンドラコミットを待つという新しいPerformance Schemaのステージは、 トランザクションコミットを行うスレッドを検出するために使用できます。 (Bug #27855592, Bug #90417)
■ セキュリティ関連
・Microsoft Windows: Windowsでは、MySQL Enterprise Editionのディストリビューションに Cyrus SASLライブラリファイルlibsasl.dllとsaslSCRAM.dllがバンドルされており、 LDAP認証プラグインがSCRAM-SHA-1認証メソッドを使用できるようになりました。 ・MySQL Enterprise Editionは、プラグインと一連のユーザー定義関数を含む プラグインライブラリとして実装されたデータマスキングと非特定化の機能を 提供するようになりました。 データマスキングは、実際の値を代わりのものに置き換えることによって機密情報を隠します。 MySQL Enterpriseのデータマスキングと非特定化の機能は、難読化（識別特性の削除）、 フォーマットされたランダムデータの生成、および、データ置換または代用などの いくつかの方法を使用して、既存のデータをマスキングすることを可能にします。 例： 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_Area()はデカルト空間参照システム（SRS）を持つ ジオメトリ引数のみをサポートし、地理的SRSを指定したジオメトリ引数を使用して呼び出すと エラーが発生しました。現在、ST_Area()は、地理的SRSを持つジオメトリ引数をサポートし、 測地領域を平方メートルで返します。 ＜注意＞ 空間データにST_Area()によって異なって解釈されたジオメトリ値が含まれている場合、 この関数を使用した既存のクエリは、以前のMySQLバージョンと比較して異なる結果を返します。 ・CREATE SPATIAL REFERENCE SYSTEMステートメントの空間参照システム（SRS）の定義の パーサーは、無効な構造を拒否することにより厳しく、地理的SRSでaxis句（軸句）を 必要とします。(Bug #28186073, Bug #28147723) ・以前は、ST_Validate()はデカルト空間参照システム（SRS）を持つジオメトリ引数のみを サポートし、地理的SRSを指定したジオメトリ引数を使用して呼び出すとエラーが発生しました。 現在、ST_Validate()は、地理的SRSを持つジオメトリ引数をサポートします。 ＜注意＞ 空間データにST_Validate()によって異なって解釈されたジオメトリ値が含まれている場合、 この関数を使用した既存のクエリは、以前のMySQLバージョンと比較して異なる結果を返します。 ・MySQLは、現在、ある空間参照システム（SRS）から別のSRSへのジオメトリ引数の変換に 使用するためのST_Transform()空間関数を実装しています。 現在、地理的SRS間の変換を サポートしています。
■ SQL構文
・互換性のない変更: GROUP BY句の廃止予定であったASCまたはDESC修飾子は削除されました。 以前GROUP BYソートに依存していたクエリは、以前のMySQLバージョンとは異なる結果を生成 する可能性があります。特定のソート順を生成するためには、ORDER BY句を使用してください。 GROUP BY句のASCまたはDESC修飾子を使用するMySQL 8.0.12以前のクエリおよび ストアドプログラムの定義は、修正する必要があります。そうしないと、 MySQL 8.0.13以降のバージョンへのアップグレードに失敗し、 MySQL 8.0.13以降のスレーブサーバーに複製される可能性があります。
■ XAトランザクション関連
・以前は、PREPARED状態のXAトランザクションのメタデータロックは、トランザクションを 実行しているクライアントの接続が切断されたか、サーバーが再起動したときに破棄される 可能性がありました。これによって、あるセッションが別のセッションの進行中の XAトランザクションによって使用されるテーブルを削除できるというような動作につながる 可能性があります。PREPARED状態のXAトランザクションのメタデータロックは、XA COMMIT またはXA ROLLBACKが実行されるまで、クライアントの切断およびサーバーの再起動を通じて 維持されます。(Bug #22710164, Bug #79940)
■ Xプラグイン関連
・重要な変更点: Xプロトコルは接続プールオプションを提供しており、小さなWebページや REST APIエンドポイントなど、MySQLサーバーへの多数の接続を開くアプリケーションの オーバーヘッドを削減できます。 Clientオブジェクトを返す新しいmysqlx.getClient（connection、options）操作を 使用してください。Clientオブジェクトを使用することによって、オープンセッション操作を 実行すると、プールから既存の現在使用されていないネットワーク接続が取得され、 それがリセットされて使用されます。セッションを閉じると、基になる接続が未使用として マークされ、それがClientオブジェクトの接続プールに返されます。 接続プールは、オプションのデータディクショナリを使用して設定されています。つまり、 デプロイされたアプリケーションは、接続文字列を変更するだけで、接続プールを使用するか しないかを切り替えることができます。 ・多数のセッションを開いたり閉じたりしているときに、複数のXプラグインクライアントセッションが 競合しないように、相互排他ロックが追加されました。(Bug＃28637947) ・Xプラグインクライアントが、サーバー上に存在しないデータベースを指定してMySQLサーバーに 接続しようとした時、エラーメッセージは、データベースがわからなかったのではなく、 アクセスが拒否されたと示しました。正しいエラーメッセージが返されるようになりました。 (Bug＃28110957) ・Xプラグインによる整数値の不正なコピーにより、正しく整列されていないメモリアクセスに 関するエラーが発生しました。その問題は修正されました。(Bug＃28070946、Bug＃90983) ・Xプラグインがデフォルトでロードされ有効になったので、エラーログのデフォルトの冗長性設定は、 XプラグインがMySQLサーバー上で利用可能であることを示すメッセージが表示されないことを 意味しました。Xプラグインがロードされたことを確認するために、システム起動中に メッセージが表示されるようになりました。(Bug #27287340) ・Xプロトコルは、現在、情報を要求する必要なしに関心のあるクライアントに情報を送信する 機能を提供しています。さらに、グループレプリケーションに関連する変更も送信されます。 この一部として、Mysqlx_notified_by_group_replicationおよび Mysqlx_notice_global_sentのステータス変数が追加されました。
■ 追加・変更された機能
・重要な変更; NDB Cluster; NDBクライアントプログラム: 廃止予定だったエラーのための--ndbオプションを削除しました。 NDBエラーコードからエラーメッセージ情報を取得するためには、 代わりにndb_perrorを使用してください。(Bug #81705, Bug #23523957) 参照: 関連項目: Bug #81704, Bug #23523926. ・重要な変更: SET以外のステートメントでのユーザー変数の設定は、以下を含む問題が原因で、 現在廃止予定です。 * ユーザー変数を含む式の評価順が未定義だった。 * 変数のデフォルトの結果型はステートメントの先頭の型に基づいており、 ステートメントの先頭にある型の値を保持する変数が同じステートメントの中で 異なる型の値を割り当てられると、意図しない影響を与える可能性があった。 * HAVING句およびGROUP BY句、ORDER BY句は、選択式リストの値を割り当てられた変数を 参照する時、その式がクライアントで評価されたために前の行の古い列の値を使用する 可能性があったので、期待どおりに動作しませんでした。 SELECT @var, @var:=@var+1などの構文は、後方互換性のため、MySQL 8.0ではまだ 受け付けられますが、将来のリリースで削除される可能性があります。 ・innodb_fsync_thresholdシステム変数によって、書き込みバッファのために閾値サイズを 定義できます。デフォルトでは、InnoDBが新しいログファイルやテーブルスペースファイルなどの 新しいデータファイルを作成すると、ファイルが完全に書き込まれた後にのみ書き込みバッファの 内容をディスクにフラッシュし、ディスク書き込みアクティビティが急増する可能性があります。 innodb_fsync_thresholdシステム変数を使用して、より小さい周期的なフラッシュを強制して、 ディスク書き込みアクティビティの急激な増加を避けることができます。(Bug #27724600) ・InnoDB: オプティマイザによって作成されたユーザー作成の一時テーブルおよび 内部の一時テーブルは、一時テーブルスペースのプールからセッションに割り当てられた セッション一時テーブルスペースに格納されるようになりました。セッションが切断されると、 その一時テーブルスペースはトランケートされ、プールに戻されます。以前のリリースでは、 一時テーブルは、一時テーブルが削除された後にディスクスペースをオペレーティングシステムに 戻さなかったグローバル一時テーブルスペース（ibtmp1）に作成されました。 innodb_temp_tablespaces_dir変数は、セッション一時テーブルスペースが作成される場所を 定義します。デフォルトの場所は、dataディレクトリの#innodb_tempディレクトリです。 INNODB_SESSION_TEMP_TABLESPACESテーブルは、セッション一時テーブルスペースに関する メタデータを提供します。 グローバル一時テーブルスペース（ibtmp1）に、ユーザー作成一時テーブルへの変更に対する ロールバックセグメントが格納されるようになりました。 ・InnoDB: InnoDBのテーブルスペース暗号化機能は、一般的なテーブルスペースをサポートするように なりました。以前は、file-per-tableのテーブルスペースのみを暗号化できました。 一般的なテーブルスペースの暗号化をサポートするために、CREATE TABLESPACEおよび ALTER TABLESPACE構文が拡張されENCRYPTION句が追加されました。 INFORMATION_SCHEMA.INNODB_TABLESPACESテーブルには、現在、テーブルスペースが 暗号化されているかどうかを示すENCRYPTIONカラムが含まれます。 stage／innodb／alter tablespace（暗号化）のパフォーマンススキーマの ステージインストゥルメントが追加され、一般的なテーブルスペースの暗号化操作の 監視を可能にしました。 ・レプリケーション: グループの実行中、変更を加えるためにすべてのメンバーを停止することなく、 グループの設定を変更できるようになりました。この機能は、このバージョンのプラグインと共に インストールされるUDFに依存し、グループのすべてのメンバーはこれらのUDFをインストールする 必要があります。UDFを使用するためには、オンラインのメンバーに接続し、SELECT UDFを 発行します。 group_replication_set_as_primary() UDFを使用して、単一プライマリーグループ内の 新しいプライマリーとしての特定のメンバーの選出をトリガーし、通常の選出プロセスを オーバーライドします。 さらに、グループがオンラインの間に使用しているモードを、シングルプライマリーモードと マルチプライマリーモードの間で変更して設定できます。 オンライングループのモードを変更するためには、次のいずれかのオプションを選択します。 * マルチプライマリーモードで動作するグループをシングルプライマリーモードに変更する ためには、group_replication_switch_to_single_primary_mode()を使用します。 * シングルプライマリーモードで動作するグループをマルチプライマリーモードに変更する ためには、group_replication_switch_to_multi_primary_mode()を使用します。 ・レプリケーション: グループのコンセンサスインスタンスの最大数をいつでも検査および設定 できるようになりました。この最大値は、グループのイベントホライズンと呼ばれ、 システムが並行して実行できるコンセンサスインスタンスの最大数です。これにより、 グループレプリケーション開発のパフォーマンスを微調整することができます。 実行時にグループのイベントホライズン値を検査するためには、次のコマンドを発行します。 SELECT group_replication_get_write_concurrency()1 書き込みコンセンサスインスタンスの最大数を設定するためには、次のコマンドを発行します。 SELECT group_replication_set_write_concurrency(instances);1 instancesは、コンセンサスに使用される最大インスタンスの新しい数です。 ・Solaris: Solarisでは、Developer Studio 12.6でMySQLを構築できるようになりました。 (Bug #27055190, Bug #88316, Bug #28165246, Bug #91214) ・データ切り捨てテストが、未定義の動作を避けるために書き直されました。 (Bug #28255956, Bug #91445) ・浮動小数点値の範囲外のチェックが改善されました。(Bug #28225635) ・起動プロセス中にサーバーが実行するアップグレードチェックでは、 パーティション分割されたInnoDBテーブルが共有テーブルスペースを使用していないことが 確認されるようになりました。(Bug＃28204431) ・以前は、mysysライブラリのI/Oキャッシュで実行されたファイルI/Oが計測されず、 バイナリログインデックスファイルについてパフォーマンススキーマによって報告された ファイルI/O統計に特に影響していました。現在、このI/Oは計測されており、 パフォーマンススキーマの統計は正確です。(Bug #27788907, Bug #90264) ・メモリ内の権限構造にユーザーアカウントエントリーを配置するためのパフォーマンスが 向上しました。(Bug #27772506, Bug #90244) ・mysqld --initializeが完了しなかったが使用できないデータディレクトリが作成された場合、 そのデータディレクトリは使用できない、安全に削除できるというメッセージが表示されるように なりました。(Bug #27675647) ・単一スレッドまたはマルチスレッドのスレーブ上の個々のアプライアースレッドによる トランザクション再試行用のパフォーマンススキーマで、Instrumentation（計測）が 提供されるようになりました。 以前は、パフォーマンススキーマテーブルのreplication_applier_status_by_workerは アプライヤスレッドを停止させたエラーに関する情報は表示しましたが、 トランザクションが最終的に適用される前に発生した一時的なエラーに関する情報は 表示しませんでした。 この情報を使用して、レプリケーションスレーブまたはグループレプリケーションの グループメンバーにレプリケーションラグを引き起こす一時的なエラーを特定できます。 パフォーマンススキーマのreplication_applier_status_by_workerテーブルに 8つの新しい列が追加されました。 * LAST_APPLIED_TRANSACTION_RETRIES_COUNT 最初の試行後に最後に適用されたトランザクションがワーカーによって再試行された回数。 トランザクションが最初の試行で適用された場合、この数値はゼロです。 * LAST_APPLIED_TRANSACTION_LAST_TRANSIENT_ERROR_NUMBER トランザクションの再試行を引き起こした最後の一時的なエラーのエラー番号。 * LAST_APPLIED_TRANSACTION_LAST_TRANSIENT_ERROR_MESSAGE トランザクションの再試行を引き起こした最後の一時的なエラーのメッセージテキスト。 * LAST_APPLIED_TRANSACTION_LAST_TRANSIENT_ERROR_TIMESTAMP トランザクションの再試行を引き起こした最後の一時的なエラーの 'YYYY-MM-DD HH：MM：SS [.fraction]'形式のタイムスタンプ。 * APPLYING_TRANSACTION_RETRIES_COUNT この時点までに現在適用されているトランザクションが再試行された回数。 トランザクションが最初の試行で適用された場合、この数値はゼロです。 * APPLYING_TRANSACTION_LAST_TRANSIENT_ERROR_NUMBER 現在のトランザクションの再試行を引き起こした最後の一時的なエラーのエラー番号。 * APPLYING_TRANSACTION_LAST_TRANSIENT_ERROR_MESSAGE 現在のトランザクションの再試行を引き起こした最後の一時的なエラーのメッセージテキスト。 * APPLYING_TRANSACTION_LAST_TRANSIENT_ERROR_TIMESTAMP 現在のトランザクションの再試行を引き起こした最後の一時的なエラーの 'YYYY-MM-DD HH：MM：SS [.fraction]'形式のタイムスタンプ。 既存の列APPLYING_TRANSACTION_START_APPLY_TIMESTAMPは、 トランザクションが再試行されるたびにリセットされなくなりました。これで、作業者が最初に トランザクションを適用しようとしたときのタイムスタンプが保持されるようになりました ・以前は、GTIDを使用する場合（つまり、enforce_gtid_consistencyシステム変数がONに 設定されている場合）、CREATE TEMPORARY TABLEとDROP TEMPORARY TABLEのステートメントは、 トランザクションまたはプロシージャ、関数、トリガー内でサポートされていませんでした。 GTIDを有効にしてこれらのステートメントを使用することは可能でしたが、 トランザクションの外でのみ、かつ、autocommit=1でのみ、可能でした。 MySQL 8.0.13から、binlog_formatがROWまたはMIXEDに設定されている場合、 この制限は解除されました。行ベースのロギングを使用すると、GTIDが有効なときに トランザクションまたはプロシージャ、ファンクション、トリガー内で CREATE TEMPORARY TABLEとDROP TEMPORARY TABLEのステートメントを使用できるように なりました。binlog_formatがSTATEMENTに設定されている場合、制限が残ります。 この動作の違いにより、現在は、実行時にbinlog_formatの設定を変更するために 追加の制限が適用されています。 * セッションにオープンしている一時テーブルがある場合、 そのセッションのレプリケーションフォーマットを変更することはできません （SET @@ SESSION.binlog_format）。 * レプリケーションチャネルに開いている一時テーブルがある場合、 レプリケーションフォーマットをグローバルに変更することはできません （SET @@ GLOBAL.binlog_formatまたはSET @@ PERSIST.binlog_format）。 * レプリケーションチャネルアプライヤスレッドが現在実行中の場合、 レプリケーションフォーマットをグローバルに変更することはできません （SET @@ GLOBAL.binlog_formatまたはSET @@ PERSIST.binlog_format）。 これらのいずれの場合でも、レプリケーションフォーマットを切り替えようとすると （または現在のレプリケーションフォーマットを設定しようとすると）、エラーが発生します。 しかしながら、PERSIST_ONLY（SET @@ PERSIST_ONLY.binlog_format）を使用して、 いつでもレプリケーションフォーマットを変更できます。なぜなら、このアクションは、 実行時のグローバルシステム変数の値を変更せず、サーバーの再起動後にのみ有効になるからです。 binlog_formatがROWまたはMIXEDに設定されている場合、CREATE TEMPORARY TABLEと DROP TEMPORARY TABLEのステートメントはバイナリログに書き込まれないため、 スレーブにはレプリケートされません。それらがトランザクションで使用されるとき、 トランザクションからこれらのステートメントを削除することで空のトランザクションが 発生すると、トランザクションはバイナリログに書き込まれません。 これらのステートメントを含むトランザクションがロールバックされると、 一時テーブルの作成または削除がロールバックできないことを示す警告メッセージが発行されます。 ・バイナリロギングのMySQL Serverコードは、バイナリログとリレーログのイベントに アクセスするための新しい内部インターフェイスを作成するためにリファクタリングされています。 新しいインターフェースは、バイナリーロギングのための書き込みと読み取りのプロセスを 入出力ストリームに分け、バイナリーログイベントのキャプチャーや取得のプロセスを それらをファイルに書き込むプロセスと切り離します。論理バイナリログファイルは、 ストレージレイヤーの操作をラッパーするために使用されます。 新しい内部インタフェースにより、MySQLサーバーは、バイナリログキャッシュやメモリバッファを 含む標準のバイナリログやリレーログファイルに加えて、バイナリログイベント用の 代替ストレージメソッドを使用できるようになりました。例えば、 グループレプリケーションは、新しいインタフェースを使用して、イベントをメモリバッファと トランザクションメッセージに直接シリアル化し、グループ内のトランザクションを調整します。 また、mysqlbinlogは標準入力からバイナリログイベントを読み込むためにそれらを使用します。 次の既存のエラーメッセージは、新しい内部インターフェイスのために、現在は廃止として マークされています。 * ER_BINLOG_CANT_OPEN_LOG * ER_BINLOG_CANT_CREATE_CACHE_FOR_LOG * ER_BINLOG_ERROR_GETTING_NEXT_LOG_FROM_INDEX * ER_RPL_RECOVERY_ERROR_FREEING_IO_CACHE * ER_GRP_RPL_REINIT_OF_INTERNAL_CACHE_FOR_READ_FAILED * ER_GRP_RPL_APPENDING_DATA_TO_INTERNAL_CACHE_FAILED * ER_GRP_RPL_REINIT_OF_INTERNAL_CACHE_FOR_WRITE_FAILED * ER_GRP_RPL_FAILED_TO_CREATE_COMMIT_CACHE * ER_GRP_RPL_REINIT_OF_COMMIT_CACHE_FOR_WRITE_FAILED ・TempTableストレージエンジンは、バイナリラージオブジェクト（BLOB）型の列のストレージを サポートするようになりました。この拡張により、BLOBデータを含む一時テーブルを使用する クエリのパフォーマンスが向上します。以前は、BLOBデータを含む一時テーブルは internal_tmp_disk_storage_engineで定義されたディスク上のストレージエンジンに 格納されました。 ・バイナリログイベントの非直列化のためのMySQL Serverコードは、 バイナリログチェックサムがサーバー上で使用されているかどうかにかかわらず、 レプリケーション中またはmysqlbinlogによる処理中の壊れた無効なイベントデータの識別と 回復力のある処理を向上させるためにリファクタリングされました。 ・以前は、RENAME TABLEを実行するためには、LOCK TABLESでロックされたテーブルがないことが 要求されました。 現在、WRITEロックでロックされているテーブルの名前または複数テーブルの名前の変更操作で WRITEロックされたテーブルの名前を変更した後のテーブルの名前を変更することが可能に なりました。 ・グループからメンバーを削除する前にグループが応答しないメンバーを待つべき時間を 定義するために、group_replication_member_expel_timeoutオプションが追加されました。 これにより、メンバーへの接続が信頼できない場合のエビクションプロセスを設定できます。
■ バグ修正
・重要なメモ: MySQL Serverに含まれるlibeventライブラリはバージョン2.1.8に
アップグレードされました。(Bug #28207237)
・InnoDB; パーティショニング: .frmファイルを参照していた古いInnoDBハンドラと
パーティショニングコードが削除されました。(Bug #27995316)
・InnoDB: DROP TABLE操作中にアサーションが発生しました。memcached APIを介して
テーブルにアクセスしていたスレッドは、テーブルを解放する前にメタデータロックを
解放しました。(Bug #28531148)
・InnoDB: LOB参照のbeing_modifiedビットが設定されましたが、ビット変更がログに記録されず、
アサーションの失敗が発生しました。(Bug #28443837)
・InnoDB: オプティマイザがInnoDBストレージエンジンを内部一時テーブルに使用した時、
Window関数が不正な結果を返しました。(Bug #28430650)
・InnoDB: サーバー時間を以前の時間に調整すると、定期的なやり直しフラッシュが
見逃されました。(Bug #28430358, Bug #90670)
・InnoDB: プライマリーキーを追加するALTER TABLE操作でセグメント化エラーが発生しました。
(Bug #28395278)
参照: この問題は次のバグのリグレッションです: Bug＃27753193。
・InnoDB: 条件付きチェックは、ReadView::complete()関数を削除し、
その機能を他の関数に分割することによって、削除されました。この変更により、
ARM 64ビットのパフォーマンスが最適化されます。(Bug＃28385211、Bug＃91759)
・InnoDB: InnoDBソースコードファイルから残りのthread_mutexコードが削除されました。
(Bug＃28363673、Bug＃91678)
・InnoDB: Microsoft Visual Studio 2017を使用してInnoDBをコンパイルする時に発生した
警告を排除するために、型の変更が実装されました。(Bug＃28338720)
・InnoDB: 共有インデックスロックを示すために使用されたB-treeフラグが
共有排他的インデックスロックを示すために使用されると、無効なアサーションが発生しました。
(Bug＃28317172)
・InnoDB: シャープなチェックポイントメカニズムは、現在利用可能なLSNのチェックポイントを
要求する時、ダーティページのプレフラッシュを強制しません。
ログチェックポインタースレッドは、次のチェックポイント書き込みが必要かどうか、
ページクリーナーを起動してダーティページの同期フラッシュを強制的に行うかどうかを決定する時に、
並行マージン（ログ内の空き領域のスレッドごとのマージン）を考慮するようになりました。
ページクリーナスレッドは、ダーティページをフラッシュするかどうか、何ページを
フラッシュするかを決定する時に並行マージンを考慮に入れます。(Bug＃28297462)
・InnoDB: 間違ったデバッグクラッシュポイントにより、トランザクションのタイムアウトが発生し、
テストが失敗しました。(Bug＃28295814)
・InnoDB: InnoDBのエラーメッセージフォーマットは、重複するテキストを削除するために
変更されました。(Bug＃28289789)
・InnoDB: メモリを解放して割り当てる不要なサイクルは、WindowsでJSONのパフォーマンス低下を
引き起こしました。(Bug＃28278737)
・InnoDB: ハードウェア最適化チェックサムが計算される度にハードウェアサポートのチェックが
行われるのを避けるために、アサートがデバッグ専用アサートに変換されました。
(Bug＃28267334、Bug＃91485)
・InnoDB: Variance-Aware Transaction Scheduling（VATS）と読み取りロックを解除する機能を
組み合わせたパッチによって、ギャップロックは待機中のトランザクションへのロックを許可する
ことなく解除され、トランザクションタイムアウトを引き起こしました。(Bug＃28261530)
参照: この問題は次のバグのリグレッションです: Bug #28261530。
・InnoDB: redoの量が少ない場合、log_checkpointerスレッドは適時に新しいチェックポイントを
書き込むことに失敗しました。(Bug＃28220222)
・InnoDB: キャッシュから外部キー関連テーブルを削除しようとしたことが原因で、
サーバーはMySQL 5.7からMySQL 8.0へのインプレースアップグレード中に終了しました。
アップグレード処理の最後に、FULLTEXTインデックス付きのテーブルは、外部キーの関係を
チェックすることなく、追い出し準備完了としてマークされました。(Bug＃28212734、Bug＃91325)
・InnoDB: 次のパフォーマンススキーマおよびINFORMATION_SCHEMAテーブルの列の形式が
変更されました。
* data_locks.ENGINE_LOCK_ID
* data_lock_waits.REQUESTING_ENGINE_LOCK_ID
* data_lock_waits.BLOCKING_ENGINE_LOCK_ID
* INNODB_TRX.TRX_REQUESTED_LOCK_ID
以前の形式は、テーブルロックの場合はtrx_id:table_id、
レコードロックの場合はtrx_id:space_id:page_no:heap_noでした。
新しい形式は、テーブルロックの場合はtrx_immutable_id:table_id:lock_immutable_id、
レコードロックの場合はtrx_immutable_id:space_id:page_no:heap_no:lock_immutable_id
です。
lock_immutable_idおよびtrx_immutable_idは、それぞれロックまたはトランザクションの
存続期間中に変更されない64ビット値で、他のインスタンスオブジェクトIDの中で一意です。
(Bug＃28176910)
・InnoDB: パフォーマンススキーマのdata_locksテーブルのLOCK_MODE列によって使用される
許可されたロックモード記述子のリストが拡張され、REC_NOT_GAP、INSERT_INTENTION、
PREDICATE、PRDT_PAGEが含まれました。REC_NOT_GAPは読み込みのみのロックを示します。
INSERT_INTENTIONは、挿入を意図したロックを示します。PREDICATEおよびPRDT_PAGE記述子は、
空間インデックスロックを示します。(Bug＃28176805)
・InnoDB: テーブル名はlower_case_table_names=2の設定の場合にmacOS上で小文字で比較されず、
サーバーを再起動した後不安定になりました。(Bug＃28170699、Bug＃91204)
・InnoDB: InnoDBのソースコードの定数値を定義するために使用されたマクロが定数式に
変更されました。(Bug＃28152926)
・InnoDB: 優先度の高いトランザクションがコミット中のトランザクションを中止する可能性がある
シナリオを防ぐために、コミット中にトランザクションがロールバックされないようにするフラグが
もっと早く設定されるようになりました。(Bug＃28140462)
・InnoDB: テーブルのプライマリーキーをスキャンしたクエリは、期待した結果を
返しませんでした。(Bug＃28104394、Bug＃91032)
・InnoDB: 不要なヘッダファイルのインクルージョンがInnoDBソースコードファイルから
削除されました。(Bug＃28086759)
・InnoDB: ログライターがREDOログの空き領域を使い果たしていることが原因の明らかな
ハングアップによって、サーバーが終了しました。(Bug＃28072385、Bug＃90993)
・InnoDB: ロック待機中にクエリが中断し、エラーが発生しました。(Bug＃28068293)
・InnoDB: MySQL 5.7からMySQL 8.0へのアップグレード後、UNDOテーブルスペースIDが
UNDOテーブルスペース範囲内にないことを示す無効な警告が発生しました。
この警告は、MySQL 5.7のインストールが個別のUNDOテーブルスペースを使用するように
設定されている場合に発生しました。(Bug＃28060337)
・InnoDB: 不完全なクローンデータディレクトリに対する起動時のエラーに関して、
エラーメッセージが改善されました。(Bug＃28032131)
・InnoDB: XA COMMIT操作中にセグメンテーションエラーが発生しました。(Bug＃27995891)
・InnoDB: 未使用のコードがTempTableストレージエンジンのソースコードから削除されました。
(Bug＃27978968)
・InnoDB: 生成された列に定義されたセカンダリインデックスを更新する時に
インデックスレコードが見つかりませんでした。(Bug＃27968952)
・InnoDB: IF条件の誤った否定演算子によって、Variance-Aware Transaction Scheduling（VATS）
アルゴリズムがテーブルロックに使用されました。(Bug＃27944920)
参照: この問題は次のバグのリグレッションです: Bug #27572937。
・InnoDB: オンラインのALTER TABLE操作の一部として適用された更新ログは、
セカンダリインデックスの更新中に古い行に生成された列の計算値を考慮されませんでした。
(Bug＃27921932)
・InnoDB: バッファプールのメモリ割り当ては、パフォーマンススキーマの
memory／innodb／buf_buf_poolの統計情報で完全には説明されませんでした。
(Bug＃27917595、Bug＃90561)
・InnoDB: 外部キー制約を含むサポートされていないDDL操作がアサーションを引き起こしました。
(Bug＃27912873)
・InnoDB: 複数のロックが検索条件に一致した時にロック関連のデバッグアサーションエラーが
発生しました。これは、誤ったロックの解除につながる可能性があります。(Bug＃27898384)
・InnoDB: オンラインのALTER TABLE操作の準備フェーズ中に中止されたインデックスを
削除する機能は、その変更を記録しませんでした。(Bug＃27879325)
・InnoDB: 並列UNDOテーブルスペーストランケートとマスターキーローテーションの操作は、
アサーションを引き起こしました。(Bug＃27872369)
・InnoDB: 割り当てられたテーブル無しでMySQL 5.7で作成された一般的なテーブルスペースは、
MySQL 8.0へのアップグレード時にエラーを引き起こしました。(Bug＃27877485)
・InnoDB: トランザクションがmutexを保持しているかどうかを識別するbooleanマーカーは、
正しい場所に配置されませんでした。(Bug＃27870035)
・InnoDB: 破棄されたテーブルの外部キーのチェックを試みると、セグメント化エラーが
発生しました。(Bug＃27804668)
・InnoDB: B-treeのバルクロード操作によって、ページが部分的に初期化された状態になる
ことがありました。(Bug＃27802098)
・InnoDB: NUMAが有効なオペレーティングシステム上のDockerコンテナ内でサーバーを起動すると、
"mbind：Operation not permitted"エラーが発生しました。(Bug＃27792853)
・InnoDB：データディクショナリのstorage-engine-privateデータフィールドに格納された
パーティションで区切られたテーブルのTABLE_ID値は、ALTER TABLE ... PARTITION操作の後、
適切に調整されませんでした。(Bug＃27784462)
・InnoDB："log writer overwriting data after checkpoint - waited too long"エラーが
原因で、サーバーが停止しました。(Bug＃27779266)
・InnoDB：innodb_flush_log_at_trx_commit=2の場合、log_flusherスレッドは、
innodb_flush_log_at_timeout設定と等しいタイムアウト期間のイベントを待つことができ、
初期化の遅延を引き起こしました。(Bug＃27762596)
・InnoDB：OPTIMIZE TABLE操作中にアサーションが発生しました。(Bug＃27753193)
・InnoDB：デッドロックによるトランザクションのロールバックによって、デバッグビルドで
アサーションエラーが発生しました。トランザクションのロールバック中、
データディクショナリにアクセスするための操可能なトランザクションの開始は
予期されませんでした。(Bug＃27729974)
・InnoDB：innodb_flush_log_at_trx_commit = 0でバイナリログが有効な場合、
DDL操作のコミットフェーズ中にREDOログが期待通りにフラッシュされませんでした。
(Bug＃27691035)
・InnoDB：REDUNDANTまたはCOMPRESSEDの行フォーマットとREAD COMMITTED分離レベルを
使用すると、LOB値の接頭辞のみと場合によっては古いLOB値の外部部分が返され、
JSONドキュメントが破損しているとみなされる可能性がありました。
LOB値の接頭辞がない場合、他のフィールドの新しい値を持つ古いLOB値が戻され、
データの矛盾が発生する可能性がありました。(Bug＃27624990)
・InnoDB：定期的なチェックポイント所有権をマスタースレッドから
ログチェックポインタスレッドに移動した後、定期的なチェックポイントの一時停止を
許可するデバッグオプションが廃止されました。デバッグオプションは、
定期的なチェックポイントを一時停止する別の方法に置き換えられました。(Bug＃27588328)
・InnoDB：空間参照識別子（SRID）を持つ列に定義された空間インデックスを持つテーブルの
トランザクションは、別のトランザクションによって更新用に選択された領域に挿入できました。
(Bug＃27577612)
・InnoDB：テーブル名の変更操作中に外部キー制約名が重複し、その後のクエリ実行中に
エラーが発生しました。(Bug＃27545888)
・InnoDB：Serialized Dictionary Information (SDI) の削除エラーによって、
アサーションが発生しました。(Bug＃27493634)
・InnoDB：LOBパージまたはロールバック中にラージオブジェクト（LOB）インデックスエントリーを
解放した後、サーバー終了が発生しました。(Bug＃27419474)
・InnoDB：ストアドプロシージャ内のステートメントの実行前に呼び出された関数では、
trx->lock.start_stmtの読み書き操作はmutexによって保護されませんでした。(Bug＃27325898)
・InnoDB：INFORMATION_SCHEMA.FILESテーブルとINFORMATION_SCHEMA.INNODB_TABLESPACES
テーブルに、MySQLインスタンスに存在する実際のUNDOテーブルスペースが表示されませんでした。
2つのデフォルトのUNDOテーブルスペースのみが表示されました。(Bug＃26820406)
・InnoDB：オンラインログの長さを決定するREDUNDANT行フォーマットの計算での不一致が原因で、
DDL操作中にエラーが発生しました。(Bug＃26375771)
・InnoDB：innodb_undo_log_truncateを有効にすると、トランザクション処理のパフォーマンスに
悪影響を及ぼしました。UNDOテーブルスペーストランケート操作中に2つのチェックポイントを
実行する代わりに、テーブルスペースファイルに属するページがディスクからフラッシュされる
ようになりました。(Bug＃26322656)
・InnoDB：同じ行の複数のバージョンがある場合のセカンダリキーからの読み取りに関連する
パフォーマンスを向上させるため、ヘルパークラスが導入されました。
(Bug＃25540277、Bug＃84958)
・InnoDB：wait／io／file／innodb／innodb_temp_fileパフォーマンススキーマインストゥルメント
によって報告されたInnodb Merge Temp Fileの場所が正しくありませんでした。
(Bug＃21339079、Bug＃77519)
・パーティショニング: 無効なパーティション定義が原因で
CREATE TABLE ... PARTITION BY ...ステートメントが失敗した場合、
サーバーは無効なPARTITION句に遭遇する前に作成された可能性のあるパーティションファイルを
削除しませんでした。(Bug #27798708)
参照: 関連項目: Bug #88043、Bug #26945644.
・パーティショニング: innodb_file_per_table=1で作成されたパーティション化されたテーブルに
対して、そのテーブルスペースを破棄した後に、FLUSH TABLES FOR EXPORTを実行することが
できました。これを試みると、ER_TABLESPACE_DISCARDEDが発生します。
(Bug #90545, Bug #27903881)
参照: 関連項目: Bug #80669、Bug #22899690.
・パーティショニング: パーティション化されたInnoDBテーブルへの更新によって
無関係な行ロックが課せられました。(Bug #87253, Bug #26553164)
・レプリケーション: グループメンバーが一時停止された後に再開され、
保留中のすべてのメッセージを処理できない時、ERROR状態になります。
しかし、残りのメンバーはそれをUNREACHABLEと見て、そのメンバーの
疑いが失効してグループから退出するまで待ちます。
この動作は変更され、何らかのエラーにより停止しているメンバーは、
離脱ビューをインストールする前に、グループからの削除を要求するために
既知のピアに接続しようとします。(Bug #28252687)
・レプリケーション: レプリケーションスレーブがSTART SLAVEステートメントで再起動されると、
パフォーマンススキーマテーブルreplication_applier_status_by_workerの
APPLYING_TRANSACTIONを開始するカラムが、シングルスレッドモードで動作している
スレーブでリセットされるようになりました。これらのカラムは、
既存のワーカースレッドがそのステートメントによって終了され、情報を保持できないため、
常にマルチスレッドスレーブ上でリセットされました。この動作は、同様に、
シングルスレッドスレーブのカラムをリセットすることによって、スレーブの設定全体で
標準化されています。(Bug＃28248026)(Bug #28248026)
・レプリケーション: 無効なgroup_replication_group_nameを使用してサーバーで
グループレプリケーションが開始された場合、サーバーは予期せず停止します。(Bug #28219136)
・レプリケーション: マルチスレッドレプリケーションスレーブが停止し、
シングルスレッドスレーブに変更され（slave_parallel_workers > 0に設定することにより）、
再起動された場合、パフォーマンススキーマテーブルreplication_applier_status_by_worker
は、古い監視情報がクリアされていなかったため、無関係なタイムスタンプを示しました。
(Bug #28191382)
・レプリケーション: メンバーがすでに再接続を試みている間に
group_replication_recovery_retry_count変数が変更された場合、
その接続の試行は無限ループになる可能性がありました。(Bug #28092714)
・レプリケーション: binlog_group_commit_sync_delayシステム変数が
ディスクへのトランザクションの同期を遅らせるための待機時間に設定され、
binlog_group_commit_sync_no_delay_countシステム変数もトランザクションの数に
設定されている時、指定された待機時間に達する前に指定された数のトランザクションに
達した場合、MySQLサーバーは待機プロシージャを終了します。サーバーは、
binlog_group_commit_sync_delayで指定された時間の1/10のデルタが経過した後に
トランザクション数をチェックし、残りの待機時間からその間隔を減算することによって、
このプロセスを管理します。
デルタの計算中の四捨五入が待機時間がデルタの倍数ではないことを意味した場合、
残りの待機時間からデルタを最終減算すると、その値は負になり、最大待機時間にラップして、
コミットがハングします。この状況で値がラップしないように、残りの待機時間のデータ型が
変更され、元の待機時間が経過するとコミットが続行されます。(Bug #28091735, Bug #91055)
・レプリケーション: デバッグビルドでは、MySQLで255を超える照合が利用できるように
なったため、アサーションが失敗しました。(Bug #28015761)
・レプリケーション: MySQLサーバーがGTIDの整合性違反を記録したが、関連するステートメントが
正常に実行されなかった後レコードを削除しなかったため、デバッグビルドでアサーションが
生成されました。この状況の処理が改善され、現在は、サーバーはトランザクションの最後に
GTID整合性違反が失敗したステートメントによって生成されたかどうかを確認し、
もしそうであれば前のGTID整合性状態を復元します。(Bug #27903831, Bug #90551)
・レプリケーション: group_replication_exit_state_action変数を使用すると、
メンバーが意図せずにグループを離れる場合のアクションを指定できます。しかし、
group_replication_start_on_bootを有効にしてサーバーを起動すると、
以下のシナリオではgroup_replication_exit_state_action変数は無視されていました。
* 有効なグループメンバー数を超えた
* メンバーシステム変数の互換性のない設定（さまざまな）
* 参加メンバーはグループよりも多くのトランザクションを持っていた
* 参加しているメンバーのバージョンがグループと互換性がなかった
(Bug #27881311)
・レプリケーション: GTIDがレプリケーションに使用されており、空のトランザクション
または置換トランザクションに同じGTIDを注入する推奨方法によって、解析エラー
（ER_PARSE_ERROR）を引き起こしたステートメントを含むトランザクションを手動で
スキップできませんでした。この動作により、スレーブはすでに使用されているGTIDを
識別し、そのGTIDを共有していた不要なトランザクションをスキップする必要があります。
しかし、解析エラーが発生した場合では、GTIDがスキップされる必要があるかどうかを
チェックされる前にステートメントが解析されたため、トランザクションがとにかく
スキップされるという意図があったとしても、レプリケーションアプライアスレッドは
解析エラーのため停止しました。
この修正により、レプリケーションアプライアスレッドは、懸念されるトランザクションが
GTIDがすでに使用されているためにスキップされる必要がある場合、解析エラーを無視する
ようになりました。この動作の変更は、mysqlbinlogによって生成されるバイナリログ出力で
構成されるワークロードの場合は適用されません。そのような状況では、エラーを発生させる
べきである時に、スキップされたトランザクションの直後に続く解析エラーを伴う
トランザクションも静かにスキップされるというリスクがあります。(Bug #27638268)
・レプリケーション: GTIDを使用するレプリケーションスレーブでRESET SLAVEステートメントが
発行された時、既存のリレーログファイルはパージされましたが、チャネルの一連の受信GTIDが
クリアされる前に置換用の新しいリレーログファイルが生成されました。したがって、
以前のGTIDのセットは、新しいリレーログファイルにPREVIOUS_GTIDSイベントとして書き込まれ、
両方のサーバーのgtid_executedのセットが空であったとしても、スレーブがマスターより多くの
GTIDを持つことを示すレプリケーションに致命的なエラーが発生しました。
現在、RESET SLAVEが発行されると、一連の受信GTIDは、新しいリレーログファイルが
生成される前にクリアされるので、この状況は発生しません。(Bug #27636289)
・レプリケーション: スレーブから肯定応答を読み取る間、準同期レプリケーションの
マスター受信スレッドはmutexを保持していましたが、半同期スレーブの追加または削除には
同じmutexが必要で、これらの操作は肯定応答アクティビティによって遅延させられました。
この問題は、スレーブから肯定応答を読むためにmutexを取得しないことによって解決されました。
(Bug #27610678, Bug #89370)
・レプリケーション: レプリケーションスレーブレポートのコードでは、デバッグビルドで
まれなエラー状況がアサーションを発生しましたが、リリースビルドではmutexがロックされたまま
返されました。mutexは、この状況で返される前にロックが解除されるようになりました。
(Bug #27448019, Bug #89421)
・レプリケーション: グループレプリケーション固有チャネルgroup_replication_applierおよび
group_replication_recoveryのリレーログ情報ログ（slave_relay_log_infoテーブル）の
エントリーは、RESET SLAVEまたはRESET SLAVE ALLコマンドによってクリアされませんでした。
(Bug #27411175)
・レプリケーション: レプリケーションスレーブでのトランザクションの自動再試行は、
slave_transaction_retriesシステム変数で指定されているように、
トランザクションが再試行で繰り返される非一時的なエラーまたはより広い問題を示したエラー
を持っていたとしても、実行されました。現在、トランザクションには、エラーがないか、
一時的なエラーしかない場合にのみ、自動的に再試行されます。(Bug #27373559, Bug #89143)
・レプリケーション: 特定のログタイプ（FLUSH SLOW LOGSなど）のFLUSHステートメントが
エラーになった場合、ステートメントはバイナリログに書き込まれました。
エラーはマスターで発生しましたが、スレーブで発生しなかったため、これはレプリケーションを
停止しました。現在、MySQL ServerはこれらのFLUSHステートメントの結果をチェックし、
エラーが発生した場合、ステートメントはバイナリログに書き込まれません。
(Bug #24786290, Bug #83232)
・レプリケーション: パスワードのハッシュを生成するPASSWORD()関数は、MySQL 5.7では
廃止予定になり、MySQL 8.0では削除されました。この関数を使用した
SET PASSWORDステートメントが、MySQL 5.6のマスターからMySQL 5.7のスレーブに、または、
log_builtin_as_identified_by_passwordシステム変数がONに設定された
MySQL 5.7のマスターからMySQL 5.7のスレーブにレプリケートされた時、
パスワードハッシュ自体もスレーブに格納される前にハッシュされました。
この問題は修正され、レプリケートされたパスワードハッシュは
もともとスレーブに渡された状態で保存されます。(Bug #24687073)
・レプリケーション: レプリケーションに関連する特定のパフォーマンススキーマテーブルから
レコードを取り出すのにORDER BY句が使用された場合、空のセットが返されました。
この問題は修正されました。(Bug #22958077, Bug #80777)
・レプリケーション: レプリケーションチャネルがマルチソースレプリケーションのために
スレーブ上で使用される場合、個別のチャネルを指定しないSTART SLAVEステートメント
（FOR CHANNEL句を使用しない）は、レプリケーションスレーブ上のすべてのチャネルの
I/OスレッドとSQLスレッドを開始します。
ただし、そのようなスレーブでRESET SLAVEステートメントが使用された場合、
後続のSTART SLAVEステートメントはデフォルト以外のチャネルを開始しませんでした。
現在、初期化プロセスのエラーの結果としてではなく、RESET SLAVEステートメントの
結果として初期化解除されたレプリケーションチャネルは、すべてのチャネルに適用される
START SLAVEステートメントによって識別され再始動されます。(Bug #22809607)
・レプリケーション: レプリケーションスレーブでRESET SLAVEを発行すると、
メモリに保持されているマスターホストやマスターポート、マスターユーザー、
マスターパスワードなどのレプリケーション接続パラメーターは変更されません。
ただし、RESET SLAVE ALLを発行すると、これらの接続パラメーターはリセットされます。
以前は、スレーブのmysqldがRESET SLAVEの発行後すぐに再起動された場合
（サーバーのクラッシュと意図的な再起動を含む）、RESET SLAVE ALLが使用されたかのように
接続パラメーターがリセットされました。
現在、master_info_repository=TABLEがサーバーに設定されている場合
（MySQL 8.0からはデフォルト）、レプリケーション接続パラメーターは、
RESET SLAVE操作の一部としてクラッシュセーフInnoDBテーブルの
mysql.slave_master_infoに保持されます。それらはメモリにも保持されます。
RESET SLAVEを発行した後でSTART SLAVEを発行する前にサーバーがクラッシュした場合や
意図的に再起動した場合、レプリケーション接続パラメーターはそのテーブルから取得され、
新しい接続に再利用されます。
サーバー上でmaster_info_repository=FILEが設定されている場合（MySQL 5.7のデフォルト）、
レプリケーション接続パラメーターはメモリ内にのみ保持されるため、その動作はこれまでと
同じままです。RESET SLAVEの発行直後のサーバーのクラッシュまたは意図的な再起動のために
スレーブのmysqldが再起動された場合、接続パラメーターは失われます。この場合、
START SLAVEを発行する前に、サーバーの起動後にCHANGE MASTER TOステートメントを
発行して接続パラメーターを再指定する必要があります。
意図的に接続パラメーターをリセットしたい場合、RESET SLAVE ALLを使用して
接続パラメーターをクリアする必要があります。その場合、サーバーの起動後に
CHANGE MASTER TOステートメントを発行して、新しい接続パラメーターを指定する
必要があります。(Bug＃20280946)
・レプリケーション: xdr_utilsの未使用機能に関連するコンパイル警告が減少しました。
(Bug #91071, Bug #28099963)
・レプリケーション: DNSベースのエントリーでそれ自身のローカルアドレスに解決されたものが
group_replication_group_seedsがに含まれる時、グループレプリケーションは
開始できませんでした。(Bug #90483, Bug #27882096, Bug #28074929)
・レプリケーション: START GROUP_REPLICATIONを発行してから、
たとえばcontrol-Cを使用してmysqldプロセスを強制的に停止すると、
予期せずサーバーが停止する可能性がありました。(Bug #90457, Bug #27873419)
・Microsoft Windows: オプションファイルのsql_modeオプションの
NO_AUTO_CREATE_USER値の存在がMySQL 8.0サーバーの起動を妨げると、
エラーがサーバーログに書き込まれるようになりました。(Bug #28061945, Bug #90967)
・Microsoft Windows: Windowsでは、MySQLインストーラによるMySQL Server MSIパッケージの
アンインストールによって、誤ったポップアップウィンドウが生成されました。(Bug #27463864)
・Microsoft Windows: Windowsでは、DBUG_ABORTはカスタムスタックトレースとその他の情報を
出力しませんでした。(Bug #21383530)
・Microsoft Windows: --installオプションの後にサービス名を指定した
service-installationコマンドを使用してWindowsサービスとしてMySQLを起動すると、
指定されたサービスグループ内のmy.iniファイルまたはmy.cnfオプションファイルの
ディレクティブが無視され、代わりにデフォルトオプションが使用されました。
デフォルトのサービス名（mysqld、mysql_cluster、server、mysqld-8.0）のみが
オプションファイルから異なるパラメーターをロードできます。
(Bug #90383, Bug #27852209)
・JSON: 生成されたカラムの式でサブクエリ、パラメーター、変数、ストアド関数、および、
ユーザー定義関数が許可されない場合でも、サーバーは、生成されたカラムがJSON_TABLE()を
使用した生成カラムのテーブルの作成を拒否しませんでした。サーバーは、
許可されていない構文（JSON_TABLE()を含む）のそのような式での使用が拒否されていることを
確認するために、より積極的にチェックします。(Bug #28518485)
・JSON: SELECT ... FROM JSON_TABLE()は、MySQL root以外のユーザーの権限エラーで
失敗することがありました。この問題は、そのようなクエリがビューの基礎として使用され、
ビューからのSELECTが失敗した場合にも発生する可能性がありました。
(Bug #28255453, Bug #27923406)
参照: 関連項目: Bug #27189940。
・JSON: JSON_TABLE()関数は、231以上の整数値をラップアラウンドしました。
例えば、次のクエリは-2147483648を返しました。
SELECT id FROM JSON_TABLE('[{"id":"2147483648"}]', '$[*]'
COLUMNS (id BIGINT UNSIGNED PATH '$.id')) AS json
(Bug #27856835)
・JSON: 一部のコンテキストでは、NULLIF()関数は最初の引数を実際の型ではなく
boolean値として返しました。これは、この関数の結果がJSON_ARRAYAGG()または
JSON_OBJECTAGG()の引数として使用された時に発見されましたが、
NULLIF()が同様の方法で使用された他のケースで発生する可能性がありました。
(Bug #90833, Bug #28007237)
・JSON: バイナリデータを含むJSONドキュメントが表示用にbase-64エンコードテキストに
変換されると、エンコードされた文字列の改行文字が適切にエスケープされず、
テキスト表示はJSONとして解析されず、トランケートされたか、破損したか、または、
その両方でした。
現在、MySQLは、エンコードされた文字列中の改行文字が必ずエスケープされるように
します。(Bug #90503, Bug #27891359)
・mysqldump --tablesの出力では、既にドットが入っているファイル名であっても、
ファイル名には常に.txtまたは.sqlの拡張子が含まれるようになりました。
(Bug＃28380961、Bug＃91745)
・SHOW CREATE TABLEは、外部キーのRESTRICTオプションを省略できました。これにより、
外部キーのRESTRICTオプションは、mysqldumpでダンプされダンプファイルから復元された
テーブルから失われる可能性がありました。(Bug＃28122781、Bug＃91110)
・mysqlクライアントは、バッチモードで大量の複数行のステートメントをインポートするのが
遅かったです。現在、この状況では、メモリの割り当てがより効率的です。
(Bug＃28116512、Bug＃85155)
・mysqlクライアントの場合、-b shortオプションは、
2つの長いオプション--no-beepと--binary-as-hexと関連していました。
-bオプションは、現在、--no-beepのみと関連付けられます。(Bug＃28093271)
・WITH_GMOCK CMakeオプションは、Windowsのパス名を適切に処理しませんでした。
(Bug＃28061409、Bug＃90964)
・mysqldumpによって生成されたANALYZE TABLE ... UPDATE HISTOGRAMステートメントには、
構文エラーが含まれました。(Bug＃28014376、Bug＃90846)
・mysqldumpダンプファイルのストアドプログラム定義には、
NO_AUTO_CREATE_USER SQLモードが含まれることがありました。
このモードはMySQL 8.0で削除されているため、そのようなダンプファイルを
MySQL 8.0サーバーにロードすることはできませんでした。mysqldumpは、現在、
ダンプされたストアドプログラムの定義からNO_AUTO_CREATE_USERを削除します。
(Bug＃27931181、Bug＃90624)
・mysqldは、インストールディレクトリが$PATHにリストされた最後のディレクトリの場合、
そのインストールディレクトリを正しく決定しませんでした。(Bug＃27922896)
・サーバーがプラグインのメタデータをデータディクショナリに格納できなかった場合、
mysql_install_pluginはプラグイン固有のエラーの報告に失敗しました。(Bug＃27893406)
・これらのスクリプトは、もうRPMパッケージには含まれていません
（それらはmysqldバイナリにコンパイルされているため不要です）:
fill_help_tables.sql, mysql_sys_schema.sql, mysql_system_tables.sql,
mysql_system_tables_data.sql, mysql_system_users.sql。(Bug＃27672991)
全ての変更点やバグ修正については、以下のページをご覧ください。
MySQL 8.0.13リリースノート（MySQLウェブサイト）： http://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-13.html
MySQL Editions
MySQLのサブスクリプションは、24時間365日体制でお客様をサポートいたします。さらに MySQL Enterprise Edition では、データベース管理者支援ツール MySQL Enterprise Monitor やバックアップツール MySQL Enterprise Backup をご利用いただけます。