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

主な変更点

■ 追加・変更された機能

・パフォーマンス：このリリースでは、スキャンのパフォーマンスが大幅に向上しました。
　その内容は以下のとおりです：

　　* 行チェックサムはハードウェアの問題の検出に役立ちますが、パフォーマンスを低下させます。
　　　NDBは、現在、新しいndb_row_checksumサーバシステム変数を0に設定することによって、
　　　これらを無効にすることができます。これを実行することは、行チェックサムが新しいテーブル
　　　または変更されたテーブルに使用されないことを意味します。これは、すべての種類のクエリの
　　　パフォーマンスに大きな影響（場合によっては5～10％）を与える可能性があります。
　　　この変数は、以前の動作との互換性を提供するために、デフォルトで1に設定されています。

　　* スキャンで構成されるクエリは、キューがビジーでない時にLDMスレッドで
　　　より長い時間実行できます。

　　* 以前は、プッシュされた条件をチェックする前にカラムが読み取られました。
　　　現在は、プッシュされた条件のチェックは、カラムを読み取る前に実行されます。

　　* 結合実行の一部として範囲スキャンを使用する時のプッシュされた結合のパフォーマンスは
　　　大幅に向上しました。

■ バグ修正

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

・NDBディスクデータ：
　ローカルチェックポイントを復元する時に、すでにデータベースに存在する行を挿入することが
　できます。これは、既存の行を最初に削除し、次にその行の新しいコピーを挿入することによって
　処理されるという期待される動作です。ディスク上のデータを含むいくつかのケースでは、NDBは
　既存の行を削除できませんでした。（Bug＃91627、Bug＃28341843）

・NDBクライアントプログラム：
　ASANビルドで明らかになったNdbImportUtil::RangeListのメモリリークを削除しました。
　（Bug＃91479、Bug＃28264144）

・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）

・ライブノードから削除された行を開始したばかりのノードにコピーする時、これらの行の
　1つ以上がゼロに等しいグローバルチェックポイントインデックスを持つ可能性があります。
　UNDOログがいっぱいになったためにフルローカルチェックポイントが開始されたのと同時に
　この問題が発生した場合、GCI = 0の行にLCP_SKIPビットが設定され、データノードの
　計画外のシャットダウンが発生します。（Bug＃28372628）

・ndbmtdは、ログスレッドのシャットダウンのために終了すると、ハングすることがありました。
　（Bug＃28027150）

・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

・ndb_mgmdサービスの再起動中、ndboutとndberrはmgmd_run()から出た後無効になり、
　mgmd_run()の次の呼び出し前にそれらにリダイレクトすると、セグメンテーション違反が
　引き起こされました。この修正により、ndboutとndberrが常に有効な状態に保たれます。
　（Bug＃17732772、Bug＃28536919）

・UNDOログバッファメモリの不足が、トランザクションメモリからのエラー 
　921 Out of transaction memory ... (increase SharedGlobalMemory)を使用して
　報告されました。

　この問題は、以下の新しいエラーコードの導入により修正されました。
　923 Out of undo buffer memory (increase UNDO_BUFFER_SIZE)
　（Bug＃92125、Bug＃28537319）

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

・復元フェーズ中にSCAN_FRAGREQ信号が到着したため、データノードに起動中に障害が発生しました。
　以前にそのノードに障害が発生した前に開始されて、障害が発生したノードの関与のために
　中断されたはずのスキャンからこの信号は生じました。 （Bug＃92059、Bug＃28518448）

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

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

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

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

・デバッグビルドの使用時、多数の同時挿入を含む作業負荷によりデータノードの障害が
　発生することがありました。(Bug #91764, Bug #28384750)

・ディスクデータテーブルが存在し、TwoPassInitialNodeRestartCopyが有効な状態で
　初期ノードが再起動している間、DBTUPは安全でないスキャンをディスクの順序で使用しました。
　そのようなスキャンはもうこの場合に採用されません。（Bug＃91724、Bug＃28378227）

・古いLCPファイルのチェックはテーブルのバージョンをテストしましたが、これは必ずしも
　信頼できるものではありませんでした。現在は、テーブルのバージョンに頼る代わりに、
　チェックはそのcreateGciより小さいmaxGCIを持つLCPファイルを無効とみなします。
　（Bug＃91637、Bug＃28346565）

・特定のケースでは、カスケード更新トリガは同じレコードに対して繰り返し実行され、最終的に
　使用可能なすべての同時操作を完了し、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

・スラッシュ（/）文字で始まる接続文字列は、ndb_mgmdによって拒否されるようになりました。
　（Bug＃90582、Bug＃27912892）

MySQL NDB Cluster 7.6.8リリースノート（MySQLウェブサイト）： https://dev.mysql.com/doc/relnotes/mysql-cluster/7.6/en/mysql-cluster-news-7-6-8.html

---