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

主な変更点

■ バグ修正

・NDBディスクデータ：
　NDBはInitialNoOfOpenFilesに関連したMaxNoOfOpenFilesを正しく検証しなかったために、
　データノードはユーザーに対してその問題の性質を明確にしていないエラーメッセージを出して
　失敗しました。（Bug #28943749）

・NDBディスクデータ：
　同じテーブルスペースに対してALTER TABLESPACE ... ADD DATAFILEを繰り返し実行すると、
　データノードがハングアップしそれらは残り、手動で強制終了した後に再開できなくなりました。
　（Bug #22605467）

・NDBクラスタAPI：
　NDBは、NdbBlob::close()で提供されるロック競合の軽減を必要としない、短期間の
　トランザクションを識別するようになり、ロック解除によってトランザクションが
　コミットまたは中止される前に単に余分な作業とラウンドトリップが実行されるだけの場合
　（自動コミットが有効になっている場合など）に、このメソッドを呼び出さなくなりました。
　（Bug #29305592）

　参照：Bug #49190、Bug #11757181。

・NDBクラスタAPI：
　最後に失敗した操作が解放されると、NdbTransactionによって保持されていた操作へのポインタが
　無効になり、アクセスされた時にNDB APIアプリケーションが失敗しました。（Bug #29275244）

・DBSPJブロックで実行されているプッシュされたJOINがクエリ実行中に相関IDを保存する必要が
　ある場合、これらの特定の相関IDは結果セットに最新のバッチを生成する時にのみ必要とされますが、
　これらのためのメモリはクエリ実行全体の存続期間に対して割り当てられました。後続のバッチは、
　追加の相関IDが保管され割り当てられることを必要とし、したがって、クエリが完了するのに十分に
　長い時間がかかった場合、これはクエリメモリの枯渇につながりました（エラー20008）。
　現在、このような場合、メモリは現在の結果バッチの存続期間に対してのみ割り当てられ、
　解放されてバッチの完了後に再利用できるようになります。（Bug #29336777）

　参照：Bug #26995027。

・ノードログ内のグローバルチェックポイントとローカルチェックポイントのストールレポートに
　NDBファイルシステム情報を提供するためのDUMP 406 (NdbfsDumpRequests)を追加しました。
　（Bug #28922609）

・DBACCとDBLQHのカーネルブロック間の競合状態は、同じ行に対する1つのトランザクション内の異なる
　操作が同時に準備され中断された場合に発生しました。これにより、前の操作が中止された時に、
　DBTUPが操作の準備を試みる可能性がありました。これは予想外のことであり、潜在的な
　データノード障害を含む未定義の動作につながる可能性があります。この問題を解決するために、
　現在DBACCとDBLQHは、操作を準備しようとする前に、すべての依存関係がまだ有効であることを
　確認するようになりました。

　　注意
　　この修正は、もともとBug #28500861として報告されていた関連する問題に
　　対して行われた以前の修正に代わるものです。

　（Bug #28893633）

・ndbinfo.cpustatテーブルは送信スレッドに関する不正確な情報を報告しました。（Bug #28884157）

・ndb_restoreの実行中に1つ以上のデータノードが予期せずシャットダウンすることがありました。
　これは、元のバックアップが作成されたクラスタと異なる数のデータノードを持つクラスタに
　復元する時に最も頻繁に発生しましたが、必ずしも限定されていません。

　この問題の根本的な原因は、スキーマトランザクションの実行の一部としてDBDICTカーネルブロックに
　よって使用され、NDBイベントの設定およびサブスクリプション処理に使用されるプロトコルと
　共有されるブロックインスタンスごとのプールから取得されたSafeCounterオブジェクトのプールの　
　枯渇です。イベントの設定とサブスクリプション処理の並行処理は、SafeCounterプールを
　使い果たす可能性があるということです。イベントおよびサブスクリプション処理はプールの枯渇に
　対処できますが、スキーマトランザクション処理はできませんでした。その結果、復元中にノードが
　シャットダウンされる可能性がありました。

　この問題は、DBDICTスキーマトランザクションに、同時NDBイベントアクティビティによって
　使い尽くされることができない予約済みSafeCounterの分離プールを提供することによって
　解決されます。（Bug #28595915）

・エラーによってコミットが失敗した後、関連するテーブルの名前を取得しようとしている間にmysqldが
　予想外にシャットダウンしました。これは内部関数ndbcluster_print_error()の問題によるものです。
　（Bug #28435082）

・1つ以上のステージングテーブルが使用されている場合、ndb_restoreはオートインクリメント値を
　正しく復元しませんでした。この修正の一環として、そのような場合、SYSTAB_0バックアップログの
　適用もブロックします。このログの内容はテーブルIDに基づいて直接適用され続け、関連のない
　テーブルのSYSTAB_0に格納されたオートインクリメント値を上書きする可能性がありました。
　（Bug #27917769、Bug #27831990）

　参照：Bug #27832033。

・ndb_restoreはアトミックではないオートインクリメント値を復元するメカニズムを採用していたため、
　ndb_restoreの複数のインスタンスが並行して使用された場合に誤ったオートインクリメント値が
　復元されるという結果をもたらす可能性がありました。（Bug #27832033）

　参照：Bug #27917769、Bug #27831990。

・ON DELETE CASCADEを使用している他のNDBテーブルの外部キーと、1つ以上のTEXTまたはBLOBカラムの
　両方を持つNDBテーブルでメモリリークが発生しました。（Bug #27484882）

・保留されている操作の相関IDの格納中にDBSPJカーネルブロック内でクエリメモリが使い果たされた場合、
　エラーステータス20000 Query aborted due to out of query memoryでクエリが中止されました。
　（Bug #26995027）

　参照：Bug #86537。

・MaxBufferedEpochsは、遅延するNDBイベントAPIサブスクライバによる行変更の過度のバッファリングを
　避けるためにデータノードで使用されます。

　1つ以上のサブスクライバからのエポックの応答がこのエポック数によって遅れると、
　非同期切断がトリガされ、データノードはサブスクリプションに使用されたバッファスペースを
　解放することができます。

　この切断は非同期なので、切断がデータノードで追加の新しいエポックが完了する前に完了していない
　場合があります。その結果、新しいエポックはGCP完了レコードを捕捉できず、次のような警告が
　生成されます。

　　1　[ndbd] ERROR    -- c_gcp_list.seize() failed...
　　2　    
　　3　...
　　4　
　　5　[ndbd] WARNING  -- ACK wo/ gcp record...

　そして、次のような警告につながります。

　　1　Disconnecting node %u because it has exceeded MaxBufferedEpochs 
　　2　(100 > 100), epoch ....

　この修正により、以下の変更が行われます。

　* GCP完了レコードプールのサイズを変更して、前述の切断処理の非同期的な性質を考慮するために
　　余分なヘッドルームが常にあることを確実にし、c_gcp_listの捕捉エラーを回避します。

　* 矛盾するフレーズ“100 > 100”を回避するために、MaxBufferedEpochsの警告の表現を変更します。

　（Bug #20344149）

・デバッグモードでREDOログを実行すると、データノードが行の割り当てを解除する時に失敗する
　可能性がありました。（Bug #93273、Bug #28955797）

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

---