MySQL 5.7.23 GA版（リリース日：2018年7月27日）

---

※注意：このリリースには、innodb_index_statsおよびinnodb_table_statsシステムテーブルへの変更が
　　　　含まれています。このリリースにアップグレードする場合は、それらの変更を追加するために
　　　　mysql_upgradeを必ず実行してください。

---

主な変更点

■ 監査ログ関連

・新しいMySQLインストールでは、MySQL Enterprise Auditで使用されるaudit_log_userテーブルの
　USERカラムとHOSTカラムに、mysql.userシステムテーブルのUserカラムとHostカラムの定義に
　対応する定義が追加されました。
　MySQL Enterprise Auditがすでにインストールされているインストールへのアップグレードの場合は、
　次のようにテーブル定義を変更することをお勧めします。

　　ALTER TABLE mysql.audit_log_user
　　　DROP FOREIGN KEY audit_log_user_ibfk_1;
　　ALTER TABLE mysql.audit_log_filter
　　　ENGINE=InnoDB;
　　ALTER TABLE mysql.audit_log_filter
　　　CONVERT TO CHARACTER SET utf8 COLLATE utf8_bin;
　　ALTER TABLE mysql.audit_log_user
　　　ENGINE=InnoDB;
　　ALTER TABLE mysql.audit_log_user
　　　CONVERT TO CHARACTER SET utf8 COLLATE utf8_bin;
　　ALTER TABLE mysql.audit_log_user
　　　MODIFY COLUMN USER VARCHAR(32);
　　ALTER TABLE mysql.audit_log_user
　　　ADD FOREIGN KEY (FILTERNAME) REFERENCES mysql.audit_log_filter(NAME);

　(Bug #23706056)

■ コンパイル関連

・Solaris: MySQLは、gccを使用してSolarisでコンパイルすることができるようになりました。
　(Bug #27802681)

■ MySQL Enterprise関連

・MySQL EnterpriseのFirewallのfirewall_whitelistテーブルには、現在、IDという名前の
　プライマリーキーカラムが含まれます。

■ セキュリティ関連

・リンクされたMySQL Commercial Server用のOpenSSLライブラリは、バージョン1.0.2oに
　アップグレードされました。新しいOpenSSLバージョンで修正された問題は、以下で
　説明されています。
　　http://www.openssl.org/news/vulnerabilities.html. 
　この変更は、Oracleが生産したMySQL ServerのMySQL Communityビルドに影響しません。
　これは、代わりにyaSSLライブラリを使用します。(Bug #28025379)

・MySQL5.7では、デフォルト認証プラグインはmysql_native_passwordです。
　MySQL8.0から、デフォルト認証プラグインはcaching_sha2_passwordに変更されました。
　caching_sha2_passwordで認証されたアカウントを使用してMySQL 5.7クライアントを
　8.0以降のサーバーに接続できるようにするために、MySQL5.7のクライアントライブラリと
　クライアントプログラムはcaching_sha2_passwordクライアント側認証プラグインを
　サポートするようになりました。これによって、デフォルト認証プラグインの違いに関わらず、
　MySQL 8.0以降のサーバーとのMySQL 5.7のクライアント接続機能の互換性が改善されます。 

■ SQL構文関連

・GROUP BY句の明示的なASCまたはDESC修飾子は、現在廃止予定で、将来のMySQLバージョンで
　削除されます。

■ 追加・変更された機能

・以前は、--ssl-mode = VERIFY_IDENTITYまたは--ssl-verify-server-certオプションに関して、
　クライアントは、接続に使用したホスト名が証明書のCommon Name値と一致していたが、
　Subject Alternative Name値と一致していないかどうかを調べました。現在、クライアントが
　OpenSSL 1.0.2以降を使用している場合、クライアントはホスト名がサーバー証明書の
　Subject Alternative Name値またはCommon Name値と一致するかどうかを確認します。
　(Bug #16211011, Bug #68052, Bug #27511233, Bug #89578)

■ バグ修正

・重要な変更：パーティション：非常に長い名前のパーティション化されたInnoDBテーブルを
　作成した後、mysql.innodb_index_statsとmysql.innodb_table_statsシステムテーブルの
　対応するエントリのtable_nameカラムは切り捨てられました。この問題を修正するために、
　これらのテーブルそれぞれのtable_nameカラムの長さが64から199文字に増やされました。
　どちらの場合でも、これはMySQL8.0のこれらのカラムの長さを同じです。
　このリリースにアップグレードする場合、mysql_upgradeを使用して、お使いのMySQLに
　これらの変更を適用してください。これに失敗した場合、MySQLは、
　テーブルmysql/innodb_table_statsにはカラム名table_nameに長さの不一致があります
　という警告を生成します。エラーログのmysql_upgradeを実行してください。
　
　※注意
　Microsoft Windowsなどのいくつかのプラットフォームは、パスの長さ（MAX_PATH）を
　最大260に制限する可能性があります。これによって、長い名前のパーティション化された
　テーブルの作成に失敗する可能性があります。NTFSの長いパス名を有効にすることによって、
　Windowsシステムでのこの問題を避けることができます。この方法に関する情報は
　お使いのシステムの資料をご覧ください。
　
　(Bug #86926, Bug #26390736)

・InnoDB: ngramの全文検索パーサーでは、カンマとピリオド文字を単語としてトークン化でき、
　これにより、boolean型と自然言語モードの検索結果の間に不一致が生じました。
　カンマとピリオド文字は、もうトークン化されなくなりました。(Bug #27847697)

・InnoDB: fsync()操作によって返されたI/Oエラーは、困難なエラーとして扱われるように
　なりました。(Bug #27805553, Bug #90296)

・InnoDB: テーブルスペースのインポート操作中に報告されたスキーマの不一致エラーは、
　不一致テーブルフラグを読み取り可能な形式で印刷することに失敗しました。(Bug #27542720)

・InnoDB: DDL操作は、FULLTEXTインデックスの最適化操作が完了するまで待機できませんでした。
　(Bug #27326796)　参照: この問題は、バグ#24938374の再発です。

・InnoDB: 読み取り専用トランザクションの不要なチェックがtrx_set_rw_mode()関数から
　削除されました。(Bug #27211287, Bug #88739)

・InnoDB: 外部キー制約を追加するDDL操作で、親テーブルに属する古いメモリオブジェクトに
　アクセスした時に、アサーションが発生しました。(Bug #27208858)

・InnoDB: 全文インデックスキャッシュ同期中のFULLTEXTインデックスを持つテーブルの
　DDL操作で、アサーション失敗が発生しました。(Bug #27082268, Bug #27095935)

・InnoDB: memcached get操作の開始後、失敗のアサーションが発生しました。(Bug #26876594)

・InnoDB: 外部キーチェック中に遭遇した壊れたインデックスIDが、アサーションを
　発生させました。(Bug #26654685)

・InnoDB: DDL操作中の内部デッドロックが発生した結果、セマフォ待機時間が長くなり、
　その後サーバーが終了しました。(Bug #26225783)

・InnoDB: 無効なロックのアップグレードが原因で、DDL操作が深刻なエラーに遭遇しました。
　(Bug #26225783)

・InnoDB: Windowsの64ビットシステムでは、無効なバッファプール設定値により、
　起動時にサーバーが終了しました。(Bug #26100239, Bug #86370)

・パーティショニング: パーティション化されたテーブルの場合、テーブルの再構築またはサーバーの
　再起動後に、パーティションの更新時間が正しくない可能性があった。(Bug #27073100)

・パーティショニング: パーティション化されたInnoDBテーブルへの更新によって、無関係な
　行ロックが実行されました。(Bug #87253, Bug #26553164)

・レプリケーション: 例えばグループに参加しているメンバのgroup_replication_group_nameが
　シードのgroup_replication_group_nameと一致しない場合など、メンバがグループに
　参加できなかった時に生成されるログメッセージが改善されました。
　これは、現在ログメッセージに記述されます。(Bug #27628695)

・レプリケーション: ER_GRP_RPL_SQL_SERVICE_FAILED_TO_RUN_SQL_QUERYエラーが
　正しく記録されませんでした。(Bug #27590534)

・レプリケーション: レプリケーションフィルタまたはバイナリログフィルタを使用すると、
　それらがXAトランザクションで更新されたテーブルに適用された時に問題が発生する可能性があります。
　テーブルをフィルタリングすると、レプリケーションスレーブ上でXAトランザクションが空になる
　ということが発生する可能性があります。そして、空のXAトランザクションはサポートされません。
　また、MySQL 8.0のデフォルトになったレプリケーションスレーブの設定
　master_info_repository = TABLEおよびrelay_log_info_repository = TABLEでは、
　データエンジントランザクションの内部状態は、フィルタリングされたXAトランザクションに続いて
　変更され、レプリケーショントランザクションコンテキストの状態と矛盾する状態になる可能性が
　あります。これらの問題のため、レプリケーションフィルタまたはバイナリログフィルタを
　XAトランザクションと組み合わせて使用することはサポートされていません。この修正により、
　新しいエラーER_XA_REPLICATION_FILTERSが追加され、このエラーは、結果としてトランザクションが
　空であるかどうかに関わらず、XAトランザクションがレプリケーションフィルタの影響を受けるたびに、
　記録されます。トランザクションが空でない場合、レプリケーションスレーブは実行し続けることが
　できますが、潜在的な問題を避けるために、XAトランザクションと共にレプリケーションフィルタを
　使用することを中止する手順を実行すべきです。トランザクションが空の場合、
　レプリケーションスレーブは停止します。その場合、レプリケーションスレーブは、
　レプリケーションプロセスの一貫性が損なわれる可能性のある未定義の状態である可能性があります。
　特に、スレーブのスレーブ上のgtid_executed設定は、マスター上の設定と矛盾する可能性があります。
　この状況を解決するためには、マスターを分離し、すべてのレプリケーションを停止し、その後、
　レプリケーショントポロジ全体でGTIDの一貫性を確認します。エラーメッセージを生成した
　XAトランザクションを元に戻してから、レプリケーションを再開してください。
　(Bug #27442477)

・レプリケーション: バイナリログトランザクションキャッシュサイズ（binlog_cache_size）より
　大きいトランザクションが処理中に一時ファイルにフラッシュされ、そのフラッシュが
　一時ディレクトリの空き不足のために失敗した場合、フラッシュエラーが正しく処理されませんでした。
　メッセージはエラーログに全く書き込まれず、バイナリログキャッシュはトランザクションが
　ロールバックされた後クリアされませんでした。現在、この状況では、サーバーは
　binlog_error_action設定に基づき適切な動作をし（サーバーをシャットダウンまたはログを停止）、
　エラーログにメッセージを書き込みます。トランザクションがロールバックされると、
　サーバーはフラッシュエラーをチェックし、何かが発生した場合はバイナリログキャッシュを
　クリアします。(Bug #27399620, Bug #89272)

・レプリケーション: macOS上のGroup Replication関連設定のIPアドレスまたはホスト名を
　使用することができませんでした。(Bug #27376511, Bug #89123, Bug #27604471)

・レプリケーション: GTIDがレプリケーションに使用される場合、スレーブ上でフィルタ―処理された
　複製トランザクションは持続されます。バイナリロギングがスレーブで有効になっている場合、
　フィルター処理されたトランザクションはバイナリログにGtid_log_eventとして書き込まれ、
　その後BEGIN文とCOMMIT文だけを含む空のトランザクションが書き込まれます。バイナリロギングが
　無効の場合、フィルタ―処理されたトランザクションのGTIDがmysql.gtid_executedテーブルに
　書き込まれます。
　このプロセスは、実行されたGTIDのセットにギャップがないこと、および、スレーブがマスターに
　再接続した場合にフィルタ―処理されたトランザクションが再び回収されないことを保証します。
　以前、このプロセスは、CREATE DATABASE、ALTER DATABASE、および、DROP DATABASEの
　ステートメントのために実行されていませんでしたが、現在は他と同様に
　これらのステートメントのために実行されています。(Bug #27308751, Bug #88891)

・レプリケーション: マルチスレッドスレーブにおいて、STOP SLAVE文がスレーブで実行され、
　その後にSTART SLAVE文が実行されると、エラーログは、後に続く初期化で
　スレーブSQLスレッドについて報告された位置と比較して、終了時にスレーブSQLスレッドの
　バイナリログ内の別の位置を報告する可能性がありました。マルチスレッドスレーブの場合、
　終了時にSQLスレッドについて報告される位置は、レプリケーションストリームが一貫していて
　ギャップがないところまでの低水準点です。その位置の前に出現したトランザクションは
　コミットされたことが保証されますが、その位置の後のトランザクションはコミットされた
　可能性もコミットされなかった可能性もあります。しかし、この低水準点は、
　ワーカースレッドを停止するプロセスが実際に実行される前に報告され、その後、低水準点は
　そのプロセス中のチェックポイントルーチンによって更新されました。ログメッセージの
　タイミングが変更され、最終的な低水準点が終了時のSQLスレッドに関する位置として
　報告されるようになりました。(Bug #27300658)

・レプリケーション: 分散されたリカバリー処理中のような特定の状況では、認証情報の
　ガベッジコレクションは必要以上に多くのデータが除去され、その結果競合は検出されませんでした。
　ガベッジコレクションの手順は、この場合を考慮に入れて、改善されました。
　(Bug #89938, Bug #27652526)

・レプリケーション: group_replication_applierチャネルのアプライヤスレッドが
　エラーに遭遇した場合、エラーメッセージのmaster_log_nameおよびend_log_posは
　正しくありませんでした。Group Replicationでは、トランザクションのイベントは、
　トランザクションが始められたメンバのバイナリログに書き込まれる前に複製されます。
　その結果、それらのイベントの最終的なmaster_log_nameとend_log_posは、
　group_replication_applierチャネルのアプライヤスレッドによってレプリカに
　適用された時点では、不明です。混乱を避けるために、現在は、
　group_replication_applierチャネルによって発生したこのようなエラーメッセージには、
　バイナリログ名とバイナリログの位置は含まれません。(Bug #89146, Bug #27368735)

MySQL 5.7.23リリースノート（MySQLウェブサイト）： http://dev.mysql.com/doc/relnotes/mysql/5.7/en/news-5-7-23.html

---