2025.01.29

MySQL

MySQL NDB Cluster 8.0.41 GAリリース(リリース日:2025年1月22日)

コンパイル関連

  • macOS: %zuで使用されるuint64_t値により、MacOSで [-Wformat] コンパイラ警告が発生しました。(バグ #37174692)
  • storage/ndb/src/common/util/cstrbuf.cppの警告を削除しました。(バグ #37049014)

バグ修正

  • NDBディスクデータ: mysqldは、256以上のディスク列を持つNDBテーブルに対してディスクスキャンを使用しませんでした。(バグ #37201922)
  • NDBレプリケーション: レプリケーションアプライヤは通常、トランザクションの適用中に発生する一時エラーを再試行します。このような再試行ロジックは、STMT_END_Fフラグがない行イベントを含むトランザクションでは実行されません。代わりに、ロックされたテーブルがまだある場合、後続のCOMMITクエリイベントを適用する際に、追加の手順でステートメントがコミットされます。一時エラーが適切に処理されなかったため、このステートメントをコミットする時に問題が発生しました。レプリカのスキップエラー機能も影響を受け、トランザクションが2回目にコミットされた時に発生したエラーのみをスキップしようとしました。
    バイナリログには、ソース上の複数のサーバーIDからの書き込みを含むエポックトランザクションが含まれています。次に、レプリカはIGNORE_SERVER_IDS ()を使用してSTMT_END_Fをフィルター処理し、アプライヤのCOMMITクエリログイベントからステートメントをコミットします。アプライヤによって更新される行の1つにロックを保持すると、エラー処理がトリガーされ、再試行が実行されずにレプリケーションがエラーで停止しました。
    現在、このようなエラーは、(行ログイベントで既に行われているように) 全てのメッセージを診断領域に記録し、トランザクションを再試行することで処理されます。(バグ #37331118)
  • NDBレプリケーション: バイナリロギングを実行するMySQLサーバーはNDB Clusterに接続すると、既存のバイナリログを確認します。見つかった場合は、ダウンストリームのレプリカがイベントの損失の可能性を検出できるように、独自のログファイルにIncidentイベントを書き込みます。このファイルに記録されたイベントのタイムスタンプが順序どおりでない可能性があるため、状況によっては問題が発生しました。Incidentイベントは他のイベントの後に書き込まれましたが、タイムスタンプはこれらの先行イベントよりも小さくなっていました。この問題は、起動時にバイナリログにインシデントを書き込む前に、以前に取得されてしばらく保持されていたタイムスタンプではなく、新しいタイムスタンプが使用されるようにすることで修正しました。(バグ #37228735)
  • NDB Cluster API: Ndb_cluster_connectionデストラクタは、非同期ログ記録メカニズムで使用されるバッファを解放し、このログ記録を担当するスレッドを停止するために、g_eventLogger::stopAsync()を呼び出します。Ndb_cluster_connectionデストラクタが呼び出される前にg_eventLoggerオブジェクトが削除された場合、アプリケーションはnullオブジェクトでメソッドを使用しようとした後に終了しました。これは、次の2つのいずれかの方法で発生する可能性があります:
    • APIプログラムがNdb_cluster_connectionを削除する前にロガーオブジェクトを削除しました。
    • Ndb_cluster_connectionが削除される前にndb_end()が呼び出されました。

    g_eventLoggerがNULLの場合、Ndb_cluster_connectionデストラクタのstopAsync()の呼び出しをスキップすることによって、この問題を解決します。この修正では、Ndb_cluster_connectionデストラクタを呼び出す前にg_eventLoggerを削除することは誤った使用法であることをAPIユーザーに通知する警告も追加されます。
    詳細については、API Initialization and Cleanupを参照してください。(バグ #37300558)

  • NDB Cluster API: APIノードとデータノードの状態の不整合の既知の原因が削除され、検出された場合の状態の不整合の処理が改善されました。このようなケースの1つでは、NDBカーネルでのスキャンエラーとAPIプログラムで発生したものを別々に処理すると、一部のスキャン後にクリーンアップが実行されませんでした。この一連の修正により、DBTCおよびAPIの状態のアラインメントエラーの処理が改善され、DBSPJでのスキャンプロトコルのタイムアウト処理も改善されました。現在では、このような状態の不整合が検出されると、データノードがそれを検出して強制的にシャットダウンするのではなく、関係するAPIノードが切断されます。 (バグ #20430083、バグ #22782511、バグ #23528433、バグ #28505289、バグ #36273474、バグ #36395384、バグ #36838756、バグ #37022773、バグ #37022901、バグ #37023549)
    参考: バグ #22782511、バグ #23528433、バグ #36273474、バグ #36395384、バグ #36838756も参照してください。
  • ndbinfo情報データベース: テーブルの作成時および削除時に、operations_per_fragmentやmemory_per_fragmentなどのndbinfoテーブルへのアクセスで、無効なデータが検査されることがありました。
    これを修正するために、これらのndbinfoテーブルのスキャン中、作成または削除されたためにこのような場合に一時的な状態にあるテーブルのフラグメントは無視されます。(バグ #37140331)
  • インデックスが欠落しているNDBテーブルを開くことをサポートするために以前行われた作業は、制約が満たされていないためにインデックスを再構築できない場合に、MySQLサーバーの機能を使用して問題を解決できるようにすることを目的としていました。インデックスが欠落していると、一部のSQLハンドラー機能が利用できなくなります。例えば、変更する行を効率的に選択するためのインデックスの使用、変更を処理する時に重複を識別すること、インデックスに依存する結合をプッシュすることです。これにより、NDB Cluster SQLノードが計画外にシャットダウンされる可能性があります。
    このような場合、サーバーは単にエラーを返すようになりました。(バグ #37299071)
  • トランスポータレイヤーの最近のリファクタリングにより、ソケットシャットダウンエラーの存在が報告されるようになりましたが、その性質は報告されませんでした。これにより、ソケットシャットダウンが要求されているが、ソケットがピアによって既に閉じられているという一般的なケースで混乱が生じました。このような混乱を避けるために、このログ記録は削除されました。(バグ #37243135)
    参照: この問題は、バグ #35750771のリグレッションです。
  • 次のSQLステートメントのように、縮小されたインラインサイズも指定すると、256個以上のBLOB列を持つNDBテーブルを作成できませんでした:
    CREATE TABLE t1 (
    pk INT PRIMARY KEY,
    b1 BLOB COMMENT 'NDB_COLUMN=BLOB_INLINE_SIZE=100',
    b2 BLOB COMMENT 'NDB_COLUMN=BLOB_INLINE_SIZE=100',
    ...,
    b256 BLOB COMMENT 'NDB_COLUMN=BLOB_INLINE_SIZE=100'
    ) ENGINE=NDBCLUSTER;

    (バグ #37201818)

  • 場合によっては、シャットダウン中にノード障害が発生すると、手動介入なしではクラスターを回復できなくなることがあります。
    システムの再起動の一環としてクラスターを自動的に回復する機能について記述していないGCI情報のセットの伝播を拒否するようにグローバルチェックポイントID (GCI) 情報の伝播 (CopyGCIメカニズム) を変更することで、この問題を修正しました。(バグ #37163647)
    参考: バグ #37162636も参照してください。
  • start_resend()で使用される変数名を改良し、ユーザーと開発者向けの関連デバッグメッセージを拡張して追加情報を追加しました。(バグ #37157987)
  • 場合によっては、COPY_FRAGREQシグナルがフラグメントスキャンロックを尊重しませんでした。 (バグ #37125935)
  • NDBがスキャン操作を終了しようとした時にAPIプロトコルタイムアウトが発生した場合、
    少なくともAPIが切断され、DBTC内のAPI障害処理によってレコードが回収されるまで、関連するDBTC ApiConnectRecordはそれ以上使用できなくなるとみなされました。
    このような場合にAPIがTCRELEASEREQ信号をDBTCに送信し、DBTC内の単一のApiConnectRecordに対してAPI障害処理を実行することで、この問題は改善されました。(バグ #37023661)
    参照: バグ #36273474、バグ #36395384、バグ #37022773、バグ #37022901、バグ #37023549も参照してください。
  • NDBストレージエンジンを使用するテーブルの場合、列コメントオプション BLOB_INLINE_SIZEはTINYBLOB列では暗黙的に無視され、指定されたサイズに関係なく、(暗黙的に) ハードコードされた256バイトの値がデフォルトで設定されていました。これは、ユーザーを誤解させるものでした。
    この問題を修正するために、TINYBLOB列ではBLOB_INLINE_SIZEを明示的に禁止し、NDBは列サイズがデフォルトで256バイトに設定されているという警告を出力するようになりました。(バグ #36725332)
  • テストの結果、システムの現在の障害番号に対するApiConnectRecord障害番号のチェックを追加したという以前の問題に対する修正が全てのケースでApiConnectRecord障害番号を初期化しないことが判明しました。(バグ #36155195)
    参照: この問題は、バグ #36028828のリグレッションです。
  • ndb_configは、非常に長いファイルパスを常に正しく処理するとは限りませんでした。
    (バグ #116748、バグ #37310680)
  • クラスターの同期中にノードIDを割り当てる時に、出どころ不明のエラーがログに記録され、ユーザーの疑問や懸念につながっていました。そのため、ノードID割り当ての問題に関連するデータノード QMGR ブロックとndb_mgmdプロセスのログ記録が改善され、このような場合に報告される内容に関するより詳細な情報が提供されるようになりました。(バグ #116351、バグ #37189356)
  • マルチ範囲スキャンでは、スキャンの2番目以降の範囲のフラグメントロックが失われる場合がありました。(バグ #111932、バグ #35660890)

全ての変更点やバグ修正については、以下のページをご覧ください。
MySQL NDB Cluster 8.0.41 リリースノート(MySQLウェブサイト):
https://dev.mysql.com/doc/relnotes/mysql-cluster/8.0/en/news-8-0-41.html


MySQL Editions

MySQL Editions
MySQLのサブスクリプションは、24時間365日体制でお客様をサポートいたします。さらに MySQL Enterprise Edition では、データベース管理者支援ツール MySQL Enterprise Monitor やバックアップツール MySQL Enterprise Backup をご利用いただけます。