監査ログ関連
- ＜command_class＞が＜name＞Execute＜/name＞に対して入力されませんでした。
詳細については、Logging Specific Event Classesを参照してください。(バグ #36686351)
コンパイル関連
- グループレプリケーション：OpenSSLエンジンインターフェースは非推奨となり、Fedoraを含む一部のLinuxディストリビューションのOpenSSL v3メインパッケージには含まれなくなりました。
ビルドの問題を回避するために、グループ通信システム（GCS）によるOpenSSLエンジンインターフェースの使用は、OpenSSLバージョン1.1より前のバージョンに制限されました。(バグ #37475769) - Linux：Oracle Linux 10でサーバーをビルドする場合は、/usr/bin/gcc (GCC 14.2.1)を使用してください。(バグ #37616148)
- バンドルされているCurlライブラリをバージョン 8.12.1にアップグレードしました。(バグ #37633587)
- FreeBSD上でAbseilをビルドできませんでした。(バグ #37611924)
- xxhash関数をlz4ライブラリ (バンドル版またはソース) から独立して使用するために、xxhash.cを独自のバイナリにコンパイルしましたが、これには多くのCMakeディレクティブを使用する必要がありました。代わりに、xxhashのインターフェースライブラリを構築し、そのような関数が使用される場所では必ずそのライブラリにリンクするようになりました。(バグ #37417386)
- lz4にバンドルされているバージョンではなく、GitHubからのxxHash-0.8.2を使用してください。 (バグ #37387318)
SQL関数とオペレーター関連
- 重要な変更: SQL関数は、リリース間で改良されると、以前は発生しなかった状況でSQLエラーをスローすることがあります。これがテーブルの制約、デフォルト式、パーティション式、または仮想列で発生すると、テーブルを開けなくなります。これにより、問題の分析（例えばSHOW CREATE TABLEなどを使用して）と対処（ALTER TABLE ... DROP ...文などを使用して）の両方ができませんでした。
現在は、サーバーのアップグレード時に、データディクショナリをスキャンして、前述のいずれかの機能を使用するテーブルを探します。これらのテーブルを開こうとして、開かない場合はユーザーに警告を表示します。このパッチはこれに対処します。このリリースで導入された--check-table-functionsサーバーオプションは、このような関数でエラーが発生した場合のサーバーの動作を指定できるようにすることで、この問題の解決に役立ちます。サーバーが開けなかったテーブルごとに警告をログに記録するためには、このオプションをWARNに設定します。ABORTに設定すると、これらの警告はWARNとしてログに記録されますが、問題が見つかった場合はサーバーのアップグレードが中止されます。
ABORTがデフォルトです。これにより、ユーザーは新しいバージョンのサーバーにアップグレードする前に、古いバージョンのサーバーを使用して問題を修正できます。WARNは問題にフラグを立てますが、ユーザーが問題に対処しながら対話型モードで続行できるようにします。(バグ #36890891)
参考: バグ #37009318 も参照してください。この問題は、バグ #98950、バグ #98951、バグ #31031886、バグ #31031888のリグレッションです。
INFORMATION_SCHEMA関連
- PROCESSLISTテーブルのパフォーマンスの問題を修正しました。(バグ #36778475)
追加または変更された機能
- 重要な変更：OpenSSLライブラリがバンドルされているプラットフォームでは、MySQL Serverへのリンク付きOpenSSLライブラリがバージョン3.0.16に更新されました。詳細については、OpenSSL 3.0 Series Release NotesおよびOpenSSL Security Advisory (11th February 2025)をご覧ください。(バグ #36033684)
- パフォーマンス；レプリケーション：バイナリログトランザクションの依存関係を追跡する際に使用されるデータ構造がTreeからankerl::unordered_dense::mapに変更されました。これにより、使用するスペースが約60%削減され、依存関係の追跡パフォーマンスが向上します。(バグ #37008442、バグ #37529256)
- InnoDB: デバッグ機能の向上のため、buf_page_t構造とbuf_block_t構造のメタデータがエラーログに出力されるようになりました。(バグ #35115629)
参考: バグ #35115601も参照してください。 - シグナル処理中に現在のクエリを印刷する際の従来の1024バイトの制限を1073741824 (1024 * 1024 * 1024)に増加しました。(バグ #37603354)
主なバグ修正
- InnoDB: innobaseコードの複数の箇所で発生していた潜在的なメモリリークを修正しました。(バグ #37403052)
- InnoDB: 特定の状況下において、修正済みまたはダーティなページが原因で、MySQLがシャットダウン中にクラッシュする可能性がありました。以下のようなエラーがログに記録されました：
[ERROR] [MY-011908] [InnoDB] [FATAL] Page [page id: space=46, page number=75] still fixed or dirty [ERROR] [MY-013183] [InnoDB] Assertion failure: buf0buf.cc:5889:ib::fatal triggered thread 139963705668608(バグ #37391519)
参考: バグ #35115601も参照してください。 - InnoDB: 空間インデックスのCHECK TABLEは、クラスター化インデックスレコードに格納されているジオメトリMBR に対してMBRを検証しませんでした。これにより、空間インデックスの動作が不正になる可能性がありました。
本リリース以降、CHECK TABLE EXTENDEDは、MBRがクラスター化インデックスレコードに格納されているMBRと一致することを検証します。 (バグ #37359538) - InnoDB: 悲観的な行更新に関する問題を修正しました。
(バグ #37292404) - InnoDB: CHECK TABLE操作で空間インデックスでの破損が誤って報告される可能性がありました。(バグ #37286473)
- InnoDB: InnoDB REDOログのリカバリに関する問題を修正しました。(バグ #37061960)
- InnoDB: index_id値の読み取りに関する問題を修正しました。(バグ #36993445、バグ #37709706)
- InnoDB: lower_case_table_namesに関する問題を修正しました。(バグ #32288105)
- InnoDB: 別のクライアントセッションによってテーブルの定義が変更されている間に、パーティションテーブルインデックスのレコード数を取得する際に、そのテーブルインデックスがチェックされませんでした。レコード数はエラーなく取得されました。
このリリース以降、レコード数を取得する際にインデックスが使用可能であることを確認するようになりました。(バグ #117459、バグ #37617773) - InnoDB: リストア操作に対するBPR_PCUR_*の位置指定に関連するコードをリファクタリングしました。(バグ #117259、バグ #37505746)
参考: この問題は、バグ #37318367のリグレッションです。 - InnoDB: MySQL 8.0.30でinnodb_spin_wait_delayに加えられた変更により、パフォーマンスに悪影響がありました。(バグ #116463、バグ #37212019)
- InnoDB: 特定の状況下で、ALTER TABLEでINPLACEを指定して列のサイズを変更すると、インデックスが有効サイズ制限（767バイト）を超える場合がありました。これは、行形式がRedundantまたはCompactであるテーブルで発生し、行形式がテーブルの作成時に明示的に定義されていませんでした。
このリリースでは、検証が実行され、無効なインデックスサイズをもたらすALTER TABLE、INPLACE操作によってエラーが返されます。(バグ #116353、バグ #37168132) - InnoDB: Clone_persist_gtidスレッドにおけるメモリリークを修正しました。
(バグ #107991、バグ #34454572) - パーティショニング: パーティションテーブルのパーティションキーの一部ではない列にNOW()を挿入すると、全てのパーティションが取得され、プルーニングは発生しませんでした。 (バグ #37397306)
- レプリケーション: ソースレプリカ構成において、レプリカで、同じテーブルに対してER_KEY_NOT_FOUNDエラーが発生し、UPDATEおよびDELETEステートメントが不規則に失敗しました。（レプリカのバイナリログとGTIDレコードは、要求された行がコミット済みであり、削除または更新されていないことを示していました。）これは、使用された行マッチングアルゴリズムがHASH_SCANであり、同じテーブル内の2つの行に同じCRC32値がある場合にレプリカで発生しました。
このようなCRC32の衝突が発生した場合、ハッシュテーブルで一致するCRC32が見つかったとしても、正しい行が更新されていることは保証されません。そのため、アルゴリズムは同じCRC32を持つ複数のエントリを反復処理し、ループ内でそれぞれのレコード全体を比較します。この問題は、このループを終了するロジックが誤っていたために発生しました。このロジックは修正されました。（バグ #37462058） - レプリケーション: asynchronous_connection_failover_delete_source()関数は、必ずしも全てのケースで期待どおりに動作しない場合がありました。(バグ #36479088)
- レプリケーション: 一部のケースで、asynchronous_connection_failover_add_source()関数が期待どおりに動作しない場合がありました。(バグ #36479083)
- レプリケーション: 一部のケースで、MASTER_POS_WAIT()が期待どおりに動作しない場合がありました。(バグ #36421684、バグ #37709187)
- レプリケーション: 一部のケースで、asynchronous_connection_failover_add_managed()関数が期待どおりに動作しない場合がありました。 (バグ #34648589)
- レプリケーション: サーバーの書き込み負荷が高い場合、パフォーマンススキーマのlog_statusテーブルに表示されるgtid_executedのバイナリログ位置が、バイナリログファイルに表示されるgtidのものと一致しませんでした。
この問題は、コミットパイプライン内のトランザクションが確実に完了するように、クエリ時にlog_statusテーブルのロック範囲を拡大することで修正しました。これにより、log_statusテーブルに対するクエリは、gtid_executedが完全に更新されるまで待機するようになり、バイナリログ内の位置との一貫性が保証されます。(バグ #102175、バグ #32442772) - グループレプリケーション：セカンダリがグループに参加すると、全てのグループメンバーがパフォーマンススキーマのreplication_group_member_statsテーブルのCOUNT_TRANSACTIONS_ROWS_VALIDATING列の値を無制限に増加させ始めることがありました。これは全てのグループメンバーのメモリ消費に影響を与え、この動作を引き起こしたセカンダリグループメンバーを再起動するか、場合によってはグループ全体を再起動することで軽減されない場合は、最終的にはスラッシングにつながります。
分析により、グループレプリケーションの開始操作に問題があることが示されました。この操作では、以前のグループ参加からのgroup_replication_applierチャネルに部分的なトランザクションがあるかどうかを確認します。見つかった場合、全ての完了したトランザクションを適用し、そのリレーログを消去した後、このチャネルが停止され、その後チャネルが再起動されます。その後、分散リカバリが実行され、グループメンバーから欠落しているデータを適用します。
この問題は、group_replication_applierチャネルを停止するためのグループレプリケーションパイプライン操作によって、certifierモジュールからの定期的なタスクが誤って停止され、一部の定期的な内部操作が実行されなくなったために発生しました。これらのタスクの1つは、コミット済みトランザクションの定期的な送信でした。この省略により、認証のためのガベージコレクションが妨げられ、その結果、パフォーマンススキーマ replication_group_member_statsテーブルのCOUNT_TRANSACTIONS_ROWS_VALIDATINGが継続的に増加しました。
この問題を解決するために、group_replication_applierチャネルを停止するパイプライン操作がcertifierモジュールに干渉しないように対策を講じました。これにより、COUNT_TRANSACTIONS_ROWS_VALIDATINGに誤った値が追加されることも防止されます。(バグ #37613510) - グループレプリケーション：グループレプリケーションの実行中、GTID_NEXTが指定された空のトランザクションやDDLステートメントなど、一部のトランザクションには書き込みセットがない場合があります。したがって、これらを並行して適用できるかどうかは不明であり、このため、グループレプリケーションは悲観的なアプローチに従い、これらを順番に実行し、パフォーマンスに影響が出る可能性があります。
DDLは順番に適用される必要がありますが、空のトランザクションに対してそのような動作を強制する実際の理由はないため、この修正により、空のトランザクションを他の非依存トランザクションと同時に適用できるようになります。(バグ #37597512、バグ #37569333) - グループレプリケーション：プライマリ i1と2つのセカンダリ i2とi3を使用してグループレプリケーションを実行しているグループで、プライマリのメモリ使用量が多いために断続的な問題が発生し始めました。セカンダリはプライマリが到達不能であると報告し始め、その後再び到達可能であるとし、プライマリも同様に、セカンダリが断続的に到達可能であると報告し始め、その後到達可能であると報告しました。このような不安定な状態が続いた後、セカンダリは元のプライマリ (i1) を除外し、新しいプライマリ (i2) を選出しました。
このような状況では、以前のプライマリ (i1) の performance_schema.replication_group_membersテーブルに対するクエリでは、mysqldプロセスがi1で再起動されるまで、長期間 (12時間以上)、i1はONLINEおよびPRIMARY、i2はONLINEおよびSECONDARY、i3はONLINEおよびSECONDARYとして報告されました。
観察された問題は、セカンダリの1つが過負荷になり、グループから断続的に離脱したり参加したりし、その接続がプライマリサーバーで繰り返し切断され再作成された時に、元のプライマリ (i1)で発生したことが判明しました。再接続プロセス中に、プライマリは接続を作成しようとした時にハングし、単一のXComスレッドがブロックされました。これは、MySQL 8.0.27で非同期形式から同期形式に変更されたXCom通信スタック上のSSL_connect()呼び出しに起因していました。ノードが過負荷になると、SSL_connect()呼び出しに応答しなくなり、接続側が無期限にブロックされたままになる可能性があります。
これを修正するために、非ブロッキングである方法で接続し、タイムアウトの場合は戻り、再試行は呼び出し元 (この特定のケースでは、別のノードに再接続しようとする時のXComスレッド) に任せるようになりました。 (バグ #34348094、バグ #36047891)
参考: バグ #37587252も参照してください。 - mysqldumpのfprintf_string()関数は、文字列のエスケープ処理に実際の引用符を使用しませんでした。(バグ #37607195)
- EXPLAINがサブクエリを正しく処理できないことがありました。(バグ #37560280)
- デマングルされた関数名がスタックトレース内で512バイトを超える場合、関数名は切り捨てられ、改行は出力されませんでした。
本リリース以降、ファイル名やデマングルされた関数などの長い文字列は、出力に直接書き込まれます。(バグ #37543598) - mysqldump は出力において特定の特殊文字を適切にエスケープしていませんでした。今回の修正により、mysqldumpはString Literalsで説明されているルールに従うようになりました。(バグ #37540722、バグ #37709163)
- 関数インデックスを持つテーブルに対する一部の操作が正しく処理されませんでした。(バグ #37523857)
- INSTALL COMPONENTを使用して不明なコンポーネントをインストールしようとすると、正しく処理されない場合がありました。(バグ #37437317)
- Audit Logプラグインは、JSON出力の書き込み時にエラーを正しく処理しませんでした。
詳細については、MySQL Enterprise Auditを参照してください。(バグ #37370439) - BEFORE INSERTトリガーを持つテーブルに影響を与えるINSERTに続くUPDATEは、INSERTによってNOT NULL列がNULLに設定されている場合、有効なサーバーのsql_modeによって許可されているはずであるにもかかわらず、NULL値エラーで拒否されることがありました。(バグ #37337527)
- 場合によっては、コンポーネントが複数のクエリを実行するために同じ接続を再利用できないことがありました。(バグ #37286895)
- ストアドルーチンのエラー処理が改善されました。 (バグ #37193011)
- ストアドルーチンがプリペアドステートメント内で正しく呼び出されない場合がありました。(バグ #37077424、バグ #37292797)
- SEL_ROOT::elementsのサイズをuint16からsize_tに増加しました。(バグ #36610878)
- マルチバイトUTF8の処理に関する問題を削除しました。(バグ #36593253)
- 集計を含むORDER BY句が正しく処理されない場合がありました。(バグ #36593244)
- UNION句を含むビューをクエリする際に、オプティマイザヒントが無視され、予期せずFORCE INDEXの使用が必要になりました。詳細については、Optimizer Hintsを参照してください。(バグ #36536936)
- 一部のサブセレクトが正しく処理されませんでした。(バグ #36421690)
- 特定のケースにおいて、無効なDDLステートメントが期待どおりに拒否されない場合がありました。(バグ #35721121)
- 内部関数 append_identifier()を改善しました。 (バグ #35633084)
- 通常、未使用のウィンドウ定義を持つビューは更新可能であるはずですが、サブクエリが含まれている場合、更新不可とマークされました。更新時にウィンドウは削除されましたが、更新を実行するには遅すぎました。
ウィンドウ定義の存在ではなくウィンドウ関数の存在をチェックし、マージ可能性をテストすることによって、この問題を解決します。これにより、ビューが更新可能になり、問題のあるUPDATEが成功します。(バグ #35507777) - 場合によっては、SETがプリペアドステートメントで正しく実行されませんでした。(バグ #35308309)
- この修正により、以下の問題が解決されます：
- Query_expression::is_set_operation() が正しく実行されないことがありました。
- DMLステートメントの一部のシーケンスによって、予期しない終了が発生する可能性がありました。
- ネストされたサブセレクトが正しく処理されないことがありました。
(バグ #34361287、バグ #35889583、バグ #35996409、バグ #36404149、バグ #37611264)
- Debianでは、パッケージ内のzipおよびgzipファイルに対して、dh_strip_nondeterminismが実行されなくなりました。(バグ #33791880)
- 無効なUTF8値に関する問題を削除しました。(バグ #27618273、バグ #37709687)
- 無効な識別子に関する問題に対処しました。(バグ #22958632、バグ #37709664)
- クエリ内でORDER BY DESCとLIMITを含む多値インデックスを使用し、LIMITで指定された値が結果の実際の行数よりも大きい場合、パフォーマンスに悪影響が出ることが確認されました。 (バグ #117085、バグ #37436310)
参考：この問題は、バグ #104897、バグ #33334911のリグレッションです。 - 条件を派生テーブルにプッシュダウンする際、条件を複製します。そして、基になるフィールドがビュー参照（つまり、マージされた派生テーブルのフィールド）である場合は、ビュー参照を削除し、それが参照する式を複製します。基になる式が外部結合の内側にあるテーブルからの定数式である場合、NULL値を生成する必要があるため、通常の定数として扱うことができません。ビュー参照を削除すると、この情報は失われ、誤った結果につながっていました。
このようなケースでは条件のプッシュダウンを回避することで、この問題を修正します。(バグ #111355、バグ #35634714)
全ての変更点やバグ修正については、以下のページをご覧ください。
MySQL 8.0.42 リリースノート（MySQLウェブサイト）：
https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-42.html
MySQL Editions
MySQLのサブスクリプションは、24時間365日体制でお客様をサポートいたします。さらに MySQL Enterprise Edition では、データベース管理者支援ツール MySQL Enterprise Monitor やバックアップツール MySQL Enterprise Backup をご利用いただけます。