主な変更点
■ バグ修正
● ndb_mgmdは、管理クライアントのSHUTDOWNコマンドの後に行うのと同じように、SIGTERMが発生した場合に正常に終了するようになりました。（バグ #32446105） ● ノードは、再起動中に、リカバリが終了するまで待機させられるのではなく、リカバリが完了する前にバックアップに参加することを許可されていました。（バグ #32381165） ● NDBバックアップの実行中にディスク容量が不足すると、クラスタが計画外にシャットダウンする可能性がありました。（バグ #32367250） ● ノードあたりのデフォルトのパーティション数（ndb_desc出力にPartitionCountとして表示）は、単一のライブノードで使用されるLDMスレッドの最小数を使用して計算され、データノードがクラスタを離れたりクラスタに参加した後（LDMスレッド数が変更された新しい設定を持つ可能性や、デフォルトのパーティション数が変更される可能性がある）でも、1回だけ実行されました。現在は、 このような場合、データノードがクラスタに参加またはクラスタを離れる時はいつも、ノードあたりのデフォルトのパーティション数が再計算されます。（バグ #32183985） ● ローカルチェックポイント（LCP）メカニズムがNDB 7.6で変更され、アイドル状態のフラグメント、つまり、最後のLCP以降変更されていないためにディスク上のメタデータの更新を必要としないフラグメントも検出されました。LCPメカニズムは、すぐに次のフラグメントの処理に進むことができました。このようなアイドル状態のフラグメントが非常に多い場合、これらをループするだけで必要なCPU消費が非常に大きくなり、ユーザートランザクションの遅延スパイクが発生しました。 このようなアイドル状態のフラグメントが処理される間には1ミリ秒の遅延がすでに挿入されました。後でテストしたところ、これは間隔が短すぎることがわかり、私たちは通常、以前に信じていたほど、これらのアイドル状態のフラグメントを完了するのに急いでいません。 この修正により、LCPを完了する緊急の必要性を示すREDOアラートがない場合、アイドル状態のフラグメントの遅延時間が20ミリ秒に延ばされます。REDOアラート状態が低い場合は、代わりに5ミリ秒待機し、アラート状態が高い場合は、1ミリ秒の遅延にフォールバックします。（バグ #32068551） 参照：バグ #31655158、バグ #31613158。 ● イベントバッファの輻輳は、バイナリロギングを実行していたSQLノードの計画外のシャットダウンにつながる可能性がありました。代わりに、（非推奨のpollEvents()メソッドではなく）Ndb::pollEvents2()を使用してこのようなエラーを適切にキャッチして処理するようにバイナリロギングハンドラを更新することで、これを修正します。（バグ #31926584） ● NDBオブジェクト数に関連する内部統計の生成は、解放されたNDBオブジェクトの過剰な数を返すことによって引き起こされる、1秒あたりのトランザクションの非常に高いレートでのトランザクション待ち時間の増加につながることがわかりました。（バグ #31790329） ● LDMごとに複数のログパーツを使用する時、REDOログの使用状況に基づくREDOアラート状態の計算は過度に積極的であったため、正しくありませんでした。
MySQL NDB Cluster 7.6.18リリースノート（MySQLウェブサイト）： https://dev.mysql.com/doc/relnotes/mysql-cluster/7.6/en/news-7-6-18.html
MySQL Editions
MySQLのサブスクリプションは、24時間365日体制でお客様をサポートいたします。さらに MySQL Enterprise Edition では、データベース管理者支援ツール MySQL Enterprise Monitor やバックアップツール MySQL Enterprise Backup をご利用いただけます。