MySQL NDB Cluster 7.6.9 GA版（リリース日：2019年1月22日）

主な変更点

■ バグ修正

・重要な変更：
　元のクラスタとは異なるデータノードIDを使用してクラスタに復元する時、ndb_restoreは
　ノードID 0に対応するファイルを開こうとしました。これを防ぐために、現在、--nodeidオプションと
　--backupidオプション（どちらもデフォルト値を持たない）は、ndb_restoreを呼び出す時、両方とも
　明示的に必要になります。(Bug＃28813708)

・パッケージング；MySQL NDB ClusterJ：
　libndbclientが一部のプラットフォームでビルドから欠けていました。(Bug #28997603)

・NDBディスクデータ：
　ログファイルグループは18を超えるUNDOログがあると、クラスタを再起動できませんでした。
　(Bug #251155785)

　参照：Bug #28922609。

・NDBレプリケーション：
　一定の非常に大きなテーブルを含むDROP DATABASE操作は、クラスタの予想外のシャットダウンを
　引き起こす可能性があります。(Bug #28855062)

・NDBレプリケーション：
　マスター上での書き込み（同じプライマリーキーに属しているBLOB列の値に影響する複数の変更が
　同じエポックの一部であるような方法で行われた）がスレーブにレプリケートされた時、
　NDB$BLOB_id_partテーブルの制約違反によりエラー1022が発生しました。(Bug #28746560)

・NDBクラスタAPI：
　NDBカーネルのSUMAブロックは、TE_ALTERイベントを送信する時、イベントのすべてのフラグメントが
　いつ送信されるかを追跡しません。NDBはイベントを受信すると、フラグメントをバッファし、すべての
　フラグメントが到着した時にイベントを処理します。送信と受信の間の時間が複数のエポックにわたる
　可能性がある場合、非常に大きなテーブルの定義に問題が発生する可能性があります。この時間中に、
　データノードで送信されるのをまだ待っているTE_ALTERのフラグメントがあるかもしれないので
　必ずしも正しくないにも関わらず、SUMAはエポックのすべてのデータを送信したことを示す
　SUB_GCP_COMPLETE_REP信号を送信する可能性があります。SUB_GCP_COMPLETE_REPを受信すると、
　そのエポックのバッファが閉じられます。そのため、TE_ALTERがようやく到着した時、NDBは
　それが以前のエポックからの複製であると見なし、それを黙って破棄します。

　SUMAカーネルブロックがSUB_TABLE_DATA信号の未送信フラグメントがあるエポックに関して
　SUB_GCP_COMPLETE_REPを決して送信しないようすることによって、この問題を修正します。

　この問題は、TE_ALTERイベントを使用するNDB APIアプリケーションに影響を与える可能性があります。
　（SQLノードはTE_ALTERイベントを使用しません。そのため、SQLノードとそれを使用する
　アプリケーションは影響を受けませんでした。）(Bug #28836474)

・結果としてMaxNoOfTablesとMaxNoOfOrderedIndexesとMaxNoOfUniqueHashIndexesの合計が減少した
　構成変更の後にデータノードが再起動された場合、一時的なエラーとバグの両方（いずれも事実ではない）
　を示唆する誤解を招くエラーメッセージが表示され失敗することがありました。

　前述のパラメータの（新しい）合計よりも大きいIDを持つテーブルオブジェクトが少なくとも1つあり、
　IDの許容される最大値がその合計によって制限されるためにこのテーブルを復元できないため、
　失敗自体は予想されます。エラーメッセージはこれを反映するように変更されており、現在は、
　これは問題の設定による恒久的なエラーであるということを示しています。(Bug＃28884880)

・管理サーバーのみを起動し、データノードを起動しなかった場合、RESTART ALLがタイムアウトし、
　最終的に失敗しました。これは、再起動の一環として、ndb_mgmdがタイマーを開始し、STOP_REQ信号を
　すべてのデータノードに送信し、それらのすべてがノード状態SL_CMVMIに達するのを待つためです。
　この問題は、STOP_REQ信号が送信されなかったために発生し、その結果データノードがSL_CMVMIに
　到達しませんでした。これは、タイマーが常に期限切れになり、再起動が失敗することを意味して
　いました。(Bug＃28728485、Bug＃28698831)

　参照：Bug #11757421。

・サポートされている最大長より長いインデックスを持つNDBテーブルでANALYZE TABLEを実行すると、
　データノードが失敗しました。(Bug #28714864)

・特定の状況において、最初の再起動中にノードがハングすることがありました。(Bug #28698831)

　参照：Bug #27622643。

・ndb_config --configinfo --xml --query-allの出力は、現在、ThreadConfigおよび
　MaxNoOfExecutionThreadsデータノードパラメータの設定変更がシステムの初期再起動
　（restart="system" initial="true"）を必要とすることを示します。(Bug #28494286)

・APIノードは、ノードがSL_STOPPINGフェーズ（グレースフルストップ）を通過していることを確認し、
　新しいトランザクションのためにそのノードの使用を停止する必要があります。これにより、
　ノードシャットダウンプロセスの後半フェーズでの発生し得る中断が最小限に抑えられます。
　APIノードは、定期的なハートビート信号を介してノード状態の変化を通知されるだけなので、
　シャットダウンしているノードとのやり取りを回避できない可能性があります。これにより、
　ハートビート間隔が長い時に、不要な障害が発生しました。現在、データノードが適切に停止されると、
　すべてのAPIノードに直接通知され、中断が最小限に抑えられます。(Bug #28380808)

・SELECT * FROM INFORMATION_SCHEMA.TABLESを実行すると、SQLノードが再起動することがありました。
　(Bug＃27613173)

・TUPスキャンまたはACCスキャンを使用して行をスキャンする時、または、プライマリーキーを使用して
　読み取りを実行する時、そのページがメモリ内で使用可能になるのを待つ必要がある間に、その行の
　読み取りを開始し、即時に中断することができます。ページ要求が後で戻った時、行を読み取ろうと
　すると無効なチェックサムが原因で失敗します。これは、行が削除されるとそのチェックサムが
　無効になるためです。

　この問題は、新しいタプルヘッダDELETE_WAITフラグを導入することで解決されます。これは、
　ディスクデータページがまだ使用できない行で行スキャンまたはPK読み取り操作を開始する前に
　チェックされ、行が最後にコミットされるとクリアされます。(Bug #27584165)

　参照：Bug #28868412。

・BLOB列を含むテーブルが削除されてから、異なる数のBLOB列で再作成されると、対応するイベントの
　予想されるクリーンアップが実行されない時の通信エラーを含む特定のエラー状況で、テーブル変更を
　監視するイベント定義が矛盾状態になる可能性があります。特に、新しいバージョンのテーブルが
　元のテーブルよりも多くのBLOB列を持つ時に、一部のイベントが失われる可能性があります。
　(Bug #27072756)

・4つ以上のデータノードを含むクラスタを非常に高い負荷で実行している時、データノードが
　エラー899 Rowid already allocatedで失敗することがありました。(Bug #25960230)

・サーバーが完全に起動する前にバイナリログの消去が要求された時、mysqldが予期せずにシャットダウン
　したために、ndb_binlog_indexテーブルから行を削除する準備はまだできていませんでした。現在、
　これが発生すると、ndb_binlog_indexテーブルの必要な削除の要求はキューに保存され、サーバーが
　完全に起動した時に実行するために保持されます。(Bug #25817834)

・起動時に、データノードはメタデータをコピーし、ローカルチェックポイントはメタデータを更新します。
　競合を避けるために、メタデータのコピー中は進行中のLCPアクティビティは一時停止されます。
　あるノードでローカルチェックポイントが一時停止され、再起動中の別のノードがこのノードの完全な
　LCPをチェックした時に、問題が発生しました。このチェックは、メタデータのコピーが完了する前に
　実際にLCPを完了させ、一時停止を途中で終了させました。現在、そのような場合、LCP完了チェックは、
　メタデータのコピーが終了し、一時停止が開始されたLCP内で予想どおりに終了するまで、一時停止した
　LCPの完了を待機します。(Bug #24827685)

・クラスターからのmysqldの非同期切断により、NDB APIトランザクションを開始しようとする後続の
　試みが失敗しました。これが大量な削除操作中に発生した場合、SQLレイヤーはHA::end_bulk_delete()
　を呼び出しました。この実装はha_ndbclusterによる実装で、トランザクションが開始されたと見なし、
　そうでない場合は失敗する可能性があります。この問題は、このメソッドによって使用される
　トランザクションポインタがそれを参照する前に設定されていることを確認することで解決されます。
　(Bug #20116393)

・NdbScanFilterは常にSQL標準に従ってNULLを処理するわけではなかったため、MySQLサーバによって
　フィルタリングされる（そうでなければ必要ない）非修飾行を送信する可能性がありました。
　(Bug＃92407、Bug＃28643463)

　参照：Bug #93977、Bug #29231709。

・NDBは、ENUM列の値と大なり（>）および小なり（<）の比較で条件プッシュダウンを使おうとしましたが、
　結果として行が省略される可能性がありました。現在、そのような比較はもはやプッシュダウン
　されません。ENUM値との等号（=）および不等号（<> /！=）の比較はこの変更による影響を受けず、
　これらの比較を含む条件はまだプッシュダウンされる可能性があります。 
　(Bug＃92321、Bug＃28610217)

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

---