MySQL NDB Cluster 7.5.12 GA版（リリース日：2018年10月23日）

主な変更点

■ バグ修正

・パッケージ化：
　予想されるNDBヘッダーファイルは、libndbclient-develの代わりにdevel RPMパッケージに
　含まれていました。（Bug＃84580、Bug＃26448330）

・MySQL NDB ClusterJ：
　BLOBまたはTEXTフィールドを含むテーブルが存在しないレコードに対してClusterJを使用して
　問い合わせされていた場合、例外（"The method is not valid in current blob state"
　（このメソッドは現在のBLOB状態では有効ではありません））が投げられました。（Bug＃28536926）

・MySQL NDB ClusterJ：
　BLOBまたはTEXTフィールドを含むテーブルでClusterJを使用してフルテーブルスキャンが
　実行されると、NullPointerExceptionが投げられました。これは、適切なオブジェクトの初期化が
　省略されたためで、現在はこの修正によって追加されています。（Bug＃28199372、Bug＃91242）

・SUMAカーネルブロックがSUB_STOP_REQ信号を受信すると、信号を実行し、次にSUB_STOP_CONFを
　使用して応答します。（この応答がAPIに送り返された後、APIはより多くのSUB_STOP_REQ信号を
　送信するためにオープンになります。）SUB_STOP_CONFを送信した後、SUMAはサブスクライバが
　存在しない場合にサブスクリプションを削除します。これには、複数のDROP_TRIG_IMPL_REQ
　メッセージをDBTUPに送信することが含まれます。LocalProxyは、最大21個の要求を並列に
　処理できます。これ以上のものは、短時間キューに入れられます。DROP_TRIG_IMPL_REQの実行が
　遅延した場合、キューが過負荷になる可能性があり、短時間キューのエラーと同時にデータノードの
　シャットダウンが発生しました。

　この問題は、DROP_TRIG_IMPL_REQ信号のキューアップではなく、DBTUPがすでに
　DROP_TRIG_IMPL_REQ信号をフルキャパシティで処理している場合に、
　SUB_STOP_REQ信号の実行を遅らせることで解決されます。（Bug＃26574003）

・遅延トリガがたくさんあると、ジョブバッファが使い果たされることがあります。これは、
　単一のトリガが多数の操作を実行できる（例えば、外部キーの親トリガは一致する子テーブルの
　複数の行に対して操作を実行する可能性がある）という事実と、基本テーブルの行の操作は
　複数のトリガを実行できるという事実によって発生する可能性があります。そのような場合、
　行の操作はバッチで実行されます。多数のトリガの実行が遅延された場合（すべての遅延トリガが
　プレコミットで実行されることを意味する）、その結果非常に多くのトリガ操作が同時に
　実行されると、データノードのジョブバッファまたは送信バッファが使い果たされる可能性が
　あります。それは、ノードの障害につながります。

　この問題は、同時トリガ操作の数と、トランザクションごとの未処理のトリガファイヤーリクエストの
　数を制限することによって修正されています。

　即時トリガの場合、同時トリガ操作を制限すると、実行待ちのトリガ数が増加する可能性があります。
　その場合、トリガレコードプールが使い果たされ、
　Too many concurrently fired triggers (increase MaxNoOfFiredTriggers)というエラーが
　発生します。これは、MaxNoOfFiredTriggersを増やしたり、ユーザートランザクションの
　バッチサイズを減らしたり、その両方を行うことで回避できます。（Bug＃22529864）

　参照：関連項目：Bug＃18229003、Bug＃27310330

・OperationRecを直列キューから並列キューに移動する時、Dbacc::startNext()は、
　並列キューの以前のすべての操作の累積OP_LOCK_MODEを反映するために必要な
　Operationrec::OP_ACC_LOCK_MODEフラグの更新に失敗しました。
　ACCロックキューのこの不一致は、引き継ぐロックが保持されていないと誤って判断したため、
　スキャンロックテイクオーバーメカニズムの失敗を引き起こしました。
　そのような一貫性のない並列ロックキューのメンバーであった操作を中止すると、
　同じ失敗がアサートを引き起こしました。（Bug＃92100、Bug＃28530928）

・DBTUPは、読み取り操作が同じトランザクション内に挿入されたタプルの値を読み取ろうとした時、
　エラーTuple corruption detected（タプルの破損が検出された）を送信しました。
　（Bug＃92009、Bug＃28500861）

・自己参照の外部キーの更新を実行すると、誤った制約違反エラーが発生する可能性があります。
　（Bug＃91965、Bug＃28486390）

　参考文献：関連項目：Bug＃90644、Bug＃27930382

・既にリリースされていたトリガの定義を参照しようとすると、NDB内部トリガ定義は、
　そのトリガの保留中のインスタンスが実行されたままの時に、削除される可能性がありました。
　これは、データノードに障害が発生する可能性がある、予測不可能なために危険である動作を
　引き起こしました。
　問題の根本的な原因は、特定のトリガーが解放されたかどうかの判断に関係するコードの
　根拠のない仮定にありました。この問題は、NDBの動作がトリガー定義が解放されたと
　判断された時に一貫していることと、期待に合っていることを確保することによって、
　解決されます。（Bug＃91894、Bug＃28451957）

・特定のケースでは、カスケード更新トリガは同じレコードに対して繰り返し実行され、最終的に
　使用可能なすべての同時操作を完了し、Error 233 Out of operation records 
　in transaction coordinator (increase MaxNoOfConcurrentOperations)が発生しました。
　MaxNoOfConcurrentOperationsがこれを回避するのに十分な高い値に設定された場合、
　この問題は非常に大量のCPUを消費するデータノードとして現れ、最終的にはタイムアウトに
　つながる可能性が非常に高くなります。（Bug＃91472、Bug＃28262259）

・プライマリキー以外のテーブルの一意のインデックスを参照している自己参照外部キーを持つ
　NDBテーブルに行を挿入しようとすると、ER_NO_REFERENCED_ROW_2で失敗しました。
　これは、一意のインデックスが更新される前にNDBが外部キー制約をチェックしていたためであり、
　制約チェックは行の検索にインデックスを使用できませんでした。現在、このような場合には、
　NDBは、挿入された行の外部キー制約をチェックする前に、すべての一意のインデックスの値が
　更新されるまで待ちます。（Bug＃90644、Bug＃27930382）

　参考文献：関連項目：Bug＃91965、Bug＃28486390

MySQL NDB Cluster 7.5.12リリースノート（MySQLウェブサイト）： https://dev.mysql.com/doc/relnotes/mysql-cluster/7.5/en/mysql-cluster-news-7-5-12.html

---