MySQL NDB Cluster 8.0.29 GA版（リリース日：2022年4月26日）

主な変更点

■ コンパイル関連

● 配列の範囲外エラーが原因で、GCC 11を使用してNDBをビルドできませんでした。（バグ #33459671）

● NDBをGCC 9を使用してコンパイルする時に発生するいくつかの-Wstringop-truncationn警告と、そのような警告の抑制を削除しました。また、ヘッダーファイル ndb_global.hから不要なインクルードを削除しました。（バグ #32233543）

■ ndbinfo情報データベース

● データベースオブジェクトに関するNDBディクショナリ情報を提供する8つの新しいテーブルがndbinfo情報データベースに追加されました。これにより、ndb_desc、ndb_select_all、および同様のユーティリティを使用せずに、mysqlクライアントでクエリを発行することにより、このタイプの大量の情報を取得できます。（フラグメント配布情報を取得するためには、引き続きndb_descを使用する必要があります。）これらのテーブルは、情報を提供するNDBオブジェクトとともに以下にリストします。
　　blobs: BLOBテーブル
　　dictionary_columns: テーブルの列
　　dictionary_tables: テーブル
　　events: イベントサブスクリプション
　　files: ディスクデータテーブルで使用されるファイル
　　foreign_keys: 外部キー
　　hash_maps: ハッシュマップ
　　index_columns: テーブルインデックス

　ndbinfoの追加の変更は、ファイルとhash_mapsのみがビューとして定義されることです。前にリストされた残りの6つのテーブルは、ndb$プレフィックスを使用して名前が付けられていなくても、実際にはベーステーブルです。その結果、これらのテーブルは、他のndbinfoベーステーブルのように非表示になりません。

■ パフォーマンススキーマ関連

● ndbclusterプラグインスレッドがパフォーマンススキーマに表示されるようになりました。スレッドとsetup_threadsテーブルには、バイナリロギングスレッド（ndb_binlogスレッド）、インデックス統計スレッド（ndb_index_statスレッド）、メタデータスレッド（ndb_metadataスレッド）の3つのスレッドが全て表示されます。

　これにより、これらのスレッドのスレッドIDとスレッドOS IDを取得して、これらのテーブルやその他のパフォーマンススキーマテーブルのクエリで使用できるようになります。

■ 追加・変更された機能

● NDB Cluster API：NDB APIは、リストから全てのデータをクリアするList::clear()メソッドを実装するようになりました。これにより、既存のリストをディクショナリメソッドlistEvents()、listIndexes()、およびlistObjects()を使用して簡単に再利用できます。

　さらに、Listデストラクタは、破棄されるリストから要素または属性を削除しようとする前にclear()を呼び出すように変更されました。（バグ #33676070）

● クライアント受信スレッドは、高負荷の場合にのみ有効になりました。「高負荷」を判断する基準は、ポーリングキュー（受信キュー）で待機しているクライアントの数がmin_active_clients_recv_thread（デフォルト：8）より大きいことでした。

　着信レプリケーションイベントを処理するバイナリログインジェクタースレッドなどの単一クライアントでも同様にそれ自体で高負荷が発生する可能性があるため、これは高負荷を判断するために不十分なメトリックでした。同じことがプッシュ結合クエリにも当てはまりました（着信TRANSID_AI信号の非常に大きなバッチが受信されます）。

　受信スレッドを変更して、完全に非アクティブ化されるのではなく、ポーリングキューでスリープするようになりました。これにより、クライアントに高負荷がかかっていない場合でも、着信信号の処理に常に使用できるようになりました。（バグ #33752914）

● このリリースで追加された--with-apply-statusオプションを指定したndb_restoreを使用して、NDBバックアップからndb_apply_statusテーブルを復元できるようになりました。場合によっては、この情報は、新しいレプリケーションリンクの新規設定に役立つことがあります。

　--with-apply-statusは、server_id値が0の行を除くndb_apply_statusテーブルの全ての行を復元します。--restore-epochを使用して、この行を復元します。

　--with-apply-statusオプションを使用するためには、ndb_restoreを呼び出す時に--restore-dataも指定する必要があります。

　（バグ #32604161、バグ #33594652）

● 以前は、ユーザークエリがインデックスがない（または壊れている）NDBテーブルを開こうとすると、MySQLサーバーでNDBエラー 4243 Index not foundが発生しました。現在、このような試みが行われると、次のように処理されます。

　　・クエリが問題のあるインデックスを使用しない場合、クエリはエラーや警告なしで成功します。
　　・クエリが欠落しているインデックスまたは壊れているインデックスを使用しようとすると、クエリは拒否され、NDBからの警告（Index idx is not available in NDB. Use "ALTER TABLE tbl ALTER INDEX idx INVISIBLE" to prevent MySQL from attempting to access it, or use "ndb_restore --rebuild-indexes" to rebuild it）とエラー（ER_NOT_KEYFILE）が表示されます。

　この変更の理由は、制約違反またはデータの欠落により、NDBテーブルのインデックスを復元できない場合があるためです。この場合、--disable-indexesを指定してndb_restoreを実行すると、インデックスなしでデータが復元されます。この変更により、データがバックアップから復元されると、SQLを使用して破損したデータを修正し、インデックスを再構築することができます。（バグ #28584066）

■ バグ修正

● 重要な変更：--ndb-batch-sizeサーバーオプションでサポートされる最大値が31536000から2147483648（2 GB）に増加しました。（バグ #21040523）

● パフォーマンス：多数の挿入を含むトランザクションを実行するマルチスレッドデータノード（ndbmtd）をプロファイリングすると、CPU時間の50％以上が内部メソッド Dblqh::findTransaction()に費やされたことがわかりました。この方法で検索されたハッシュリストにコミットされていないトランザクションに属する操作がたくさんあると、ハッシュバケットがいっぱいになり、その結果ハッシュバケットの検索にCPUサイクルが過剰に消費されてしまうことがわかりました。

　この問題に対処するために、ハッシュバケットの数を4095に固定し、操作の最大数に対してハッシュバケットのサイズをスケーリングして、比較的少数のアイテムのみを同じバケットに配置する必要があります。（バグ #33803541）

　参照：バグ #33803487。

● パフォーマンス：同じトランザクションで非常に多くの行を空のテーブルまたは小さなテーブルに挿入すると、行が挿入される速度は最初の速度の50％未満に急速に低下しました。その後、全てのCPU時間の約50％がDbacc::getElement()に費やされたことが判明し、根本的な原因は、DBACCによって要素を格納するために使用される構造のサイズを変更し、同じトランザクションにさらに行を挿入すると拡大し、コミット後に縮小するタイミングであると特定されました。

　要素の挿入または削除の直後にサイズを変更する必要があるかどうかを確認することで、この問題を修正します。これは、その後の挿入の拒否も処理します。（バグ #33803487）

　参照：バグ #33803541。

● パフォーマンス：次の問題により、（内部メソッド EventBufData_hash::search()を使用して）イベントバッファデータハッシュの検索にかなりの時間が費やされていました。

　　・ハッシュバケットリストが非常に大きくなる可能性がある場合、高負荷ではバケットの数が少なすぎることが判明しました。
　　・ハッシュバケットは、リンクリストを使用して実装されました。長いリンクリストをトラバースすると、非常に非効率になる可能性があります。

　リンクリストではなくベクトル（std::vector）を使用し、ハッシュバケットのセットを含む配列を拡張可能にすることによって、これらの問題を修正します。（バグ #33796754）

● パフォーマンス：内部関数 computeXorChecksum()が実装され、コンパイラが最適なコードを生成するのを支援するために細心の注意が払われましたが、過剰なCPUリソースを消費し、より単純な実装ほどパフォーマンスが良くないことがわかりました。この関数は、配列全体でXOR結果を合計するループで再実装されました。これにより、GCCコンパイラとClangコンパイラの両方で最適化が向上するようです。（バグ #33757412）

● Microsoft Windows：CompressedLCPデータノード設定パラメータは、Windowsプラットフォームに影響を与えませんでした。

　注意：
　このリリースにアップグレードすると、WindowsユーザーはCompressedLCPの設定を確認する必要があります。以前に有効にされていた場合、アップグレード後、負荷がかかっている時、または、ノードの再起動の一部としてデータを復元する時、または、その両方の時に、I/OスレッドによるCPU使用率が増加する可能性があります。この動作が望ましくない場合は、CompressedLCPを無効にします。

　（バグ #33727690）

● Microsoft Windows：内部関数 Win32AsyncFile::rmrfReq()は、どちらかの条件が発生する可能性がある場合に、ERROR_FILE_NOT_FOUNDとERROR_PATH_NOT_FOUNDの両方を常にチェックするとは限りませんでした。（バグ #33727647）

● Microsoft Windows：Windowsプラットフォームでのファイル処理で発生したいくつかのマイナーな問題を修正しました。（バグ #33727629）

● NDBレプリケーション：ALTER TABLEのコピーに関するものを含む、NDBテーブルで特定のスキーマ操作を実行すると、レプリカのmysql.ndb_apply_statusテーブルのエポック列が0に更新されましたが、これは、NDBCLUSTER以外のストレージエンジンから発信されたトランザクションに対してのみ発生するべきです。

　これを修正するために、前のサーバーIDと同じサーバーIDからndb_apply_statusに行を書き込む時に、バイナリログの位置（のみ）を更新するようになりましたが、スキーマ操作を適用する時に現在のエポックを上書きしません。（バグ #14139386）

● NDB Cluster API：内部APIメソッドを使用したハッシュキーの生成 NdbBlob::getBlobKeyHash()は、キーの最上位バイトを無視しました。これにより、NDB API BLOBハッシュリストで不必要に不均一な分布が発生しまし、キー値を比較する必要性が高まり、CPU使用率が増加しました。（バグ #33803583）

　参照：バグ #33783274。

● NDB Cluster API：Dictionary::listEvents()によって返されるリストを反復処理する時にヒットする可能性のあった不要なアサーションを削除しました。（バグ #33630835）

● GCC 11を使用したUbuntu 21.10でのビルドは、-Werror=maybe-uninitializedで停止しました。（バグ #33976268）

● 場合によっては、NDBがデータノードのノードIDを正しく処理しませんでした。（バグ #33916404）

● 場合によっては、NDBはデータノードの全てのノードIDを正しく検証しませんでした。（バグ #33896409）

● 場合によっては、配列インデックスが正しく処理されませんでした。（バグ #33896389、バグ #33896399、バグ #33916134）

● 場合によっては、整数が正しく処理されませんでした。（バグ #33896356）

● AutomaticThreadConfig設定パラメータを実装するためにNDB 8.0.23で行われた作業の一環として、ndbmtdでサポートされるLQHスレッドとTCスレッドの最大数がそれぞれ129から332と160に引き上げられました。これは、いくつかのNDBカーネルブロックによって実装された execSEND_PACKED()メソッドのパフォーマンスに悪影響を及ぼし、スケジューラーが現在のブロックスレッドの実行を一時停止しようとしている時にパックされたシグナルの送信を完了します。これは、配列のサイズが大きくなったにもかかわらず、そのようなスレッドの配列を単純に反復し続けたことが原因でした。これを修正するために、ビットマスクを使用して、完全な配列と一緒にスレッドの状態を追跡します。（バグ #33856371）

● BLOB列を操作する時、NDBは、BLOBヘッド列とBLOBパーツ行を読み書きするための操作を追加する必要があります。これらの操作は、トランザクションの実行時にトランザクションの操作リストの末尾に自動的に追加されます。

　特定の操作の前に新しい操作を挿入するためには、前の操作のリストの長さLに比例するコストで、最初から目的の操作が見つかるまで操作リストをトラバースする必要がありました。これはだいたい L2 / 2であり、リストに操作が追加されるにつれて増加します。ブロブを変更する多数の操作がバッチで定義された時、このトラバーサルコストは操作ごとに支払われました。これは、blobの読み取りと書き込みの時のパフォーマンスに顕著な影響を及ぼしました。

　blob操作を定義する時にこの種の不要なトラバーサルを排除するためにNdbTransaction::execute()でリストスプライシングを使用することによってこれを修正します。（バグ #33797931）

● ブロックスレッドスケジューラは、update_sched_config()を頻繁に呼び出して、スケジューリング戦略を更新します。これには、ノードの内部ブロックスレッド間で信号を送信するために使用されるジョブバッファキューの充足度をチェックすることが含まれます。これらのキューがいっぱいになりそうになると、スレッドスケジューラは、ジョブバッファへのプレッシャーを軽減するために、次のラウンドのmax_signalsにより小さい値を割り当てます。最小空きしきい値に達すると、スケジューラは、コンシューマースレッドがいくつかのジョブバッファスロットを解放するのを待っている間、CPUを解放します。

　以前の問題に対するNDB 8.0.18の修正により、この下限しきい値に達した場合でもメインスレッドが実行を継続できるメカニズムが導入されました。場合によっては、メインスレッドが予備に保持されているものを含む全てのジョブバッファを消費し、リソースの枯渇によりデータノードが計画外にシャットダウンすることがありました。（バグ #33792362、バグ #33872577）

　参照：この問題は、バグ #29887068のリグレッションです。

● ThreadConfigパラメータ（例えば、ThreadConfig=ldm={cpubind=1},query={cpubind=2}）を使用して1つのLDMスレッドと1つのクエリスレッドでクラスタをセットアップすると、データノードが計画外にシャットダウンしました。

　これは、メインスレッドまたはリクエストスレッドが明示的に割り当てられていない場合に、内部スレッド変数に間違った値が割り当てられたことが原因でした。現在、このような場合は、予想どおりに、最初の受信スレッドのスレッド番号がこれらに割り当てられていることを確認します。（バグ #33791270）

● 文字以外のデータのNdbEventBufferハッシュキー生成では、同じ256個のハッシュキーが再利用されました。さらに、ハッシュキーを計算する時に、長さがゼロの文字列は無視されました。（バグ #33783274）

● EventBytesRecvdCountイベントカウンターに基づくNDB API統計の収集では、過度のオーバーヘッドが発生しました。現在、このカウンターは、別の関数呼び出しで全てのイベントバッファデータをトラバースするのではなく、イベントバッファがいっぱいになると集計される値を使用して更新されます。

　（バグ #33778923）

● 内部メソッド THRConfig::reorganize_ldm_bindings()が予期しない動作をし、AutomaticThreadConfigが既にスレッドを正しいCPUにバインドした後にスレッドバインディングを変更する場合がありました。メソッドを削除し、設定データの解析やスレッドの追加時にそれを使用しなくすることで、これを修正します。（バグ #33764260）

● レシーバースレッドIDは、内部メソッド TransporterFacade::raise_thread_prio()でハードコーディングされているため、送信スレッドから呼び出された場合でも、レシーバースレッドの優先度を上げるように常に機能します。（バグ #33752983）

● NDB 8.0.28の修正により、データノードが稼働しているかどうかをチェックする Ndb_index_statを含む様々なNDBコンポーネントで使用されるコードの問題が解決されました。複数のSQLノードを持つクラスターでは、これにより、ndb_index_stat_headテーブルにテーブルイベントを作成しようとするインデックス統計スレッド間の競合状態の頻度が増加しました。つまり、2つのSQLノードが同時にイベントを作成しようとする可能性があり、SQLノードが失われるとError 746 Event name already existsが発生しました。このエラーが原因で、バイナリロギングスレッドは、インデックス統計スレッドが自身のセットアップが完了したことを通知するのを待機することになり、2番目のSQLノードが--ndb-wait-setup秒後にCould not create index stat system tablesでタイムアウトしました。（バグ #33728909）

　参照：この問題は、バグ #32019119のリグレッションです。

● 書き込みエラーの場合、ndbxfrmによって出力されたメッセージは、宛先ファイルではなくソースファイルを参照していました。（バグ #33727551）

● 複雑なネストされた結合は、FirstInner/Upper has to be an ancestor or a siblingというエラーで拒否されました。これは、SPJ APIでプッシュ結合を定義するために使用される内部 NdbQueryOperationインターフェイスによってスローされ、インターフェイスのjoin-nest依存関係が適切に定義されていないことを示します。

　問題を示すクエリには、結合ネスト構造 t2, t1, (t3, (t5, t4))がありました。t5またはt4のどちらの結合条件にも、テーブル t3への参照または明示的な依存関係はありませんでしたが、t3と同じネスト内のネストにあるため、それぞれにt3への暗黙の依存関係がありました。

　プッシュ結合を準備する時、NDBは、テーブルと結合ネストの間で必要な全てのテーブル依存関係を、各テーブルのm_ancestorビットマスクに追加することによって追跡します。ネストレベルの依存関係の場合、それらは全て、関連するネストの最初のテーブルに追加する必要があります。特定のテーブルに関連する依存関係が計算される時、それらには、結合条件で明示的に参照される全てのテーブルのセットに加えて、結合条件で参照される最上位のテーブルによって制限される、テーブルがメンバーである結合ネストによる暗黙の依存関係が含まれます。

　この特定の結合クエリでは、最も近い上部のネスト（t3で始まるネスト）にテーブルへの参照がない可能性があることを適切に考慮していませんでした。このような場合、参照される最上位のテーブルを含むネストまでの全てのネストに依存します。この最上位のテーブルに到達するまで祖先のネストの依存関係を追加するwhileループを導入することで、この問題を修正します。（バグ #33670002）

● NDBによって内部的に使用される一時メモリプール（TransientPool）が256 MBを超えると、その後プールを縮小しようとするとエラーが発生し、最終的にデータノードの計画外のシャットダウンが発生しました。（バグ #33647601）

● パーティションの統計についてクエリする前に、NDBへの接続が設定されていることを確認する。（バグ #33643512）

● 順序付きインデックスPRIMARYがndb_sql_metadataテーブルに対して作成されていない場合、インデックスが欠落しているため、保存されたGrantの適用を続行できませんでした。

　関連するCREATE TABLEステートメントをスキーマトランザクションでラップしてユーティリティテーブル（ndb_sql_metadataを含む）の作成を保護し、ロールバックによるステートメントの拒否を処理することによって、これを修正します。また、新しく作成されたテーブルが正しく作成されなかった場合は、それは削除されます。これらの変更により、部分的にしか作成されていないテーブルが残らないようになり、そのため、ユーティリティテーブルを作成する次の試みは、プロセスの最初から開始されます。（バグ #33634453）

● NDBは、config.iniグローバル設定の数値パラメータ値に続く任意の（および無効な）文字列を受け入れました。例えば、OverloadLimit=10 "M12L" または OverloadLimit=10 M（スペースを含む）のいずれかを使用して、それをOverloadLimit=10Mとして解釈することができます。

　OverloadLimit=Mのように、期待される数値の代わりに裸の文字の接尾辞を使用して、それをゼロとして解釈することも可能でした。これは、最初の文字がMySQLの標準修飾子 K、M、またはGのいずれかである任意の文字列でも発生しました。したがって、OverloadLimit=MAX_UINTには、OverloadLimitをゼロに設定する効果もありました。

　現在、接尾辞 K、M、またはGのいずれか1つだけが数値パラメータ値で受け入れられ、空白文字や引用符を挟まずに、数値の直後に続く必要があります。つまり、OverloadLimitを10メガバイトに設定するためには、OverloadLimit=10000000、OverloadLimit=10M、またはOverloadLimit=10000Kのいずれかを使用する必要があります。

　注意：
　可用性を維持するために、config.iniファイルで、この変更の結果として適用されたルールに準拠していない設定を確認し、アップグレードする前にそれらを修正する必要があります。そうしないと、問題を修正するまで、その後クラスターを開始できない場合があります。

　（バグ #33589961）

● 使用可能なCPUが8個未満の場合にAutomaticThreadConfigを有効にすると、データノードが計画外にシャットダウンしました。（バグ #33588734）

● 未使用のソースファイル buddy.cppおよびbuddy.hppをstorage/ndb/src/common/transporter/から削除しました。（バグ #33575155）

● NDBのstored grantsメカニズムにより、セッション変数 print_identified_with_as_hexがtrueに設定されるようになり、ndb_sql_metadataテーブルに格納されているパスワードハッシュが文字列ではなく16進値としてフォーマットされるようになりました。（バグ #33542052）

● バイナリログスレッドのイベント処理には、オプションの高冗長ログが含まれます。これを有効にしてNDBへの接続が失われると、次のような過剰なログメッセージが生成されます。
　　datetime 2 [Note] [MY-010866] [Server] NDB Binlog: cluster failure for epoch 55/0.
　　datetime 2 [Note] [MY-010866] [Server] NDB Binlog: cluster failure for epoch 55/0.

　エラーの診断にはあまり役立たない、このような繰り返しのログメッセージは削除されました。これにより、このような場合、スキーマ配布イベント操作のティアダウンの処理から、1つの同様のログメッセージが残ります。（バグ #33492244）

● 歴史的には、移植可能な方法でNDBコードベースの様々な相互依存性と仮定のコンパイル時チェックを実施するために、多くの異なる方法が使用されてきました。標準のstatic_assert()関数が常に使用できるようになったため、NDB_STATIC_ASSERTマクロおよびSTATIC_ASSERTマクロはstatic_assert()の直接使用に置き換えられました。（バグ #33466577）

● 内部AbstractQueryPlanインターフェイスが特定のテーブルに使用されるアクセスタイプを決定すると、テーブルにrefアクセスタイプが指定され、後でeq_refによってアクセス可能であることが判明したオプティマイザの問題を回避しようとしました。その回避策は、実際にrefアクセスを必要とするテーブルのeq_refアクセスを時々決定することによる新しい問題を導入しました。さらに、以前の修正では、MySQL Optimizerがrefアクセスと見なした場合でも、eq_refまたはフルテーブルスキャンアクセスのいずれかを必要とするUNIQUE USING HASHインデックスが考慮されていませんでした。

　（前の問題の適切な修正によって廃止された）回避策を最初に削除し、次にハッシュインデックスのeq_refまたはfull_table_scanアクセスの設定を導入することによって、これを修正します。（バグ #33451256）

　参照：この問題は、バグ #28965762のリグレッションです。

● プッシュ結合が準備されているが実行されていない時、Ndb_pushed_queries_droppedステータス変数がインクリメントされます。これに加えて、NDBは、Prepared pushed join could not be executed...という警告を発するようになりました。これはER_GET_ERRMSGに渡されます。（バグ #33449000）

● ndbdの非推奨の-rオプションが削除されました。さらに、この変更により、ndbd --helpの出力から無関係なテキストも削除されます。（バグ #33362935）

　参照：バグ #31565810。

● ndb_importは、Windows/DOSスタイル（\r\n）の改行を含む.csvファイルを正しく解析できない場合がありました。（バグ #32006725）

● ndb_importツールは、テーブルに明示的なプライマリキーがない場合にNDBによって定義された非表示のプライマリキーのみを処理しました。これにより、同じ行がLOAD DATA INFILEによって受け入れられた場合でも、自動インクリメントのプライマリキー列にNULLを含む行を挿入するとエラーが発生しました。

　自動インクリメントのプライマリキー列にNULLのインスタンスが1つ以上あるテーブルをインポートするためのサポートを追加することで、これを修正します。これには、テーブルに自動インクリメント列が1つしかないことのチェックが含まれます。この列がNULL可能である場合、ndb_importによってNOT NULLとして再定義され、この列でNULLが発生すると、行をNDBに挿入する前に、生成された自動インクリメント値に置き換えられます。（バグ #30799495）

● ノード障害が検出されると、このノードと同じノードグループ内の存続しているノードは、バッファリングされた変更データをイベントサブスクライバに再送信しようとします。未処理のエポック配信がなかった場合、つまり、未確認のGCIのリストが空の場合、存続しているノードは、このリストが空になることはないという誤った仮定をしました。（バグ #30509416）

● 外部キーの親テーブルのコピーALTER TABLEを実行し、SQLノードが完了する前に終了すると、全ての子テーブルに（追加の、一時的な）外部キーを持つ無関係な一時テーブルが残されました。この問題の1つの結果は、mysqldump --no-dataを使用して作成されたバックアップを復元できなかったことです。

　これを修正するために、NDBは、mysqldプロセスがクラスターに接続（または再接続）する度に一時テーブルのクリーンアップを実行するようになりました。（バグ #24935788、バグ #29892252）

● Mac OS X for ARMでバスエラーが発生した後、計画外のデータノードのシャットダウンが発生しました。これを修正するために、実行中にシグナルされている条件が失われないようにするために、NdbMutex_Unlock()の前に実行されるように呼び出しをNdbCondition_Signal()（AsyncIoThread.cpp内）に移動します。つまりミューテックスの中に。（バグ #105522、バグ #33559219）

● DblqhMain.cppで、内部execSCAN_FRAGREQ()関数の戻り値が欠落していると、致命的でないエラーを挿入した時にデータノードが計画外にシャットダウンされました。さらに、同じ関数に存在する条件!seize_op_rec(tcConnectptr)が実際にチェックされることはありませんでした。（バグ #105051、バグ #33401830、バグ #33671869）

● MaxNoOfFiredTriggers、MaxNoOfLocalScans、およびMaxNoOfLocalOperationsのいずれかをTransactionMemoryと同時に設定することは可能でしたが、これは許可されていません。

　さらに、MaxNoOfConcurrentTransactions、MaxNoOfConcurrentOperations、またはMaxNoOfConcurrentScansをTransactionMemoryと同時に設定することはできませんでした。しかし、これを防ぐ理由はありません。

　どちらの場合も、同時設定の動作は、TransactionMemoryパラメータのドキュメントと一致するようになりました。（バグ #102509、バグ #32474988）

● REDOログ部分が操作のログエントリをすぐに受け入れることができない場合、操作（準備、コミット、または中止）はキューに入れられるか、（準備のみ）オプションで中止されます。デフォルトでは、操作はキューに入れられます。

　このメカニズムは、ローカルデータマネージャーとREDOログ部分の分離の一部として8.0.23で変更され、ログ部分の全てのアクティビティが静止するまで、キューに入れられた操作をキューに入れられた状態のままにすることができるというリグレッションが導入されました。これが発生した場合、DBTCが操作をタイムアウトと宣言し、中止するまで、操作はキューに入れられたままになる可能性がありました。（バグ #102502、バグ #32478380）

MySQL NDB Cluster 8.0.29リリースノート（MySQLウェブサイト）： https://dev.mysql.com/doc/relnotes/mysql-cluster/8.0/en/news-8-0-29.html