MySQL NDB Cluster 8.0.23 GA版（リリース日：2021年1月18日）

主な変更点

■ 非推奨と削除関連

● 重要な変更：MySQL8.0.21およびNDB8.0.21で開始された用語の変更の一環として、ndb_slave_conflict_roleシステム変数は非推奨になり、ndb_conflict_roleに置き換えられています。

　さらに、以下に示すように、いくつかのステータス変数が非推奨になり、置き換えられています。

　＜非推奨のNDBステータス変数とその置き換え＞
　非推奨の変数　→　置き換え
　Ndb_api_adaptive_send_deferred_count_slave　→　Ndb_api_adaptive_send_deferred_count_replica
　Ndb_api_adaptive_send_forced_count_slave　→　Ndb_api_adaptive_send_forced_count_replica
　Ndb_api_adaptive_send_unforced_count_slave　→　Ndb_api_adaptive_send_unforced_count_replica
　Ndb_api_bytes_received_count_slave　→　Ndb_api_bytes_received_count_replica
　Ndb_api_bytes_sent_count_slave　→　Ndb_api_bytes_sent_count_replica
　Ndb_api_pk_op_count_slave　→　Ndb_api_pk_op_count_replica
　Ndb_api_pruned_scan_count_slave　→　Ndb_api_pruned_scan_count_replica
　Ndb_api_range_scan_count_slave　→　Ndb_api_range_scan_count_replica
　Ndb_api_read_row_count_slave　→　Ndb_api_read_row_count_replica
　Ndb_api_scan_batch_count_slave　→　Ndb_api_scan_batch_count_replica
　Ndb_api_table_scan_count_slave　→　Ndb_api_table_scan_count_replica
　Ndb_api_trans_abort_count_slave　→　Ndb_api_trans_abort_count_replica
　Ndb_api_trans_close_count_slave　→　Ndb_api_trans_close_count_replica
　Ndb_api_trans_commit_count_slave　→　Ndb_api_trans_commit_count_replica
　Ndb_api_trans_local_read_row_count_slave　→　Ndb_api_trans_local_read_row_count_replica
　Ndb_api_trans_start_count_slave　→　Ndb_api_trans_start_count_replica
　Ndb_api_uk_op_count_slave　→　Ndb_api_uk_op_count_replica
　Ndb_api_wait_exec_complete_count_slave　→　Ndb_api_wait_exec_complete_count_replica
　Ndb_api_wait_meta_request_count_slave　→　Ndb_api_wait_meta_request_count_replica
　Ndb_api_wait_nanos_count_slave　→　Ndb_api_wait_nanos_count_replica
　Ndb_api_wait_scan_result_count_slave　→　Ndb_api_wait_scan_result_count_replica
　Ndb_slave_max_replicated_epoch　→　Ndb_replica_max_replicated_epoch

　また、この作業の一環として、ndbinfo.table_distribution_statusテーブルのtab_copy_status列の値ADD_TABLE_MASTERとADD_TABLE_SLAVEは非推奨になり、それぞれADD_TABLE_COORDINATORとADD_TABLE_PARTICIPANTに置き換えられています。

　最後に、ndb_restoreなどの一部のNDBユーティリティプログラムの--help出力が更新されました。（バグ #31571031）

● NDBクライアントプログラム：このリリース以降、MySQL NDB Clusterの自動インストーラ（ndb_setup.py）は、NDB Clusterのバイナリおよびソースディストリビューションから削除され、サポートされなくなりました。（バグ #32084831）

　参照：バグ #31888835。

● ndbmemcache：NDB Clusterの以前のリリースで非推奨であったndbmemcacheは、NDB Clusterから削除され、サポートされなくなりました。（バグ #32106576）

■ 追加・変更された機能

● 以前にNDB 8.0で行われた作業の一環として、NDBディクショナリ内のNDBテーブルの表現とMySQLデータディクショナリ内のそれに対応するものの間の自動同期の一部として実行されるメタデータチェックは、テーブルレベルのプロパティに加えて、列とインデックスと外部キーのプロパティを含むように拡張されました。（このチェックは、CREATE TABLEステートメントを実行する時と、NDBテーブルを開く時にデバッグMySQLサーバーによっても行われます。）

　この作業の一環として、NDBディクショナリ内のオブジェクトのプロパティとMySQLデータディクショナリの間に見つかった不一致がMySQLエラーログに書き込まれるようになりました。エラーログメッセージには、プロパティの名前、NDBディクショナリ内のその値、MySQLデータディクショナリ内のその値が含まれます。オブジェクトが列、インデックス、または、外部キーの場合、オブジェクトのタイプもメッセージに示されます。

● ThreadConfigパラメータは、LDMスレッドのスケールアウトを目的とした、クエリスレッドとリカバリスレッドの2つの新しいスレッドタイプで拡張されました。クエリスレッドの数は、LDMスレッドの数の倍数である必要があり、最大でLDMスレッドの数の3倍までです。

　ThreadConfigを設定して、これらの引数のいずれかまたは両方を0に設定することにより、メインスレッドとrepスレッドを1つのスレッドに結合することも可能になりました。

　これらの引数の1つが0に設定され、もう1つが1に設定されたままの場合、結果として結合されるスレッドの名前はmain_repになります。両方が0に設定されている場合、それらはrecvスレッドと結合され（recvが1であると想定）、この結合されたスレッドの名前はmain_rep_recvになります。これらのスレッド名は、ndbinfo情報データベースのスレッドテーブルをチェックすると表示される名前です。

　さらに、既存のスレッドタイプの数の最大値が増加しました。新しい最大値は次のとおりです。LDMスレッドは332、TCスレッドは128、受信スレッドは64、送信スレッドは64、メインスレッドは2です。（クエリスレッドとリカバリスレッドの最大値はそれぞれ332です。）他のスレッドタイプの最大値は、NDB Clusterの以前のリリースから変更されていません。

　この作業に関連する別の変更により、32を超えるブロックスレッドが使用されている場合、NDBはジョブバッファを保護するためにミューテックスを使用します。これにより、パフォーマンスがわずかに低下する可能性があります（およそ1～2％）が、非常に大規模な設定で使用されるメモリの量も減少します。例えば、以前は2GBのジョブバッファメモリを使用していた64スレッドの設定では、現在は代わりに約1GBしか必要ありません。私たちのテストにおいて、これにより、非常に複雑なクエリの実行が全体的に改善されました（5％程度）。

● このリリースでは、新しいデータノード設定パラメータAutomaticThreadConfigを実装することにより、マルチスレッドデータノード（ndbmtd）のスレッドを自動的に設定できる可能性が追加されています。1に設定すると、NDBは、アプリケーションで使用可能なプロセッサの数に基づいて、スレッド割り当てを自動的に設定します。システムがプロセッサの数を制限していない場合、NumCPUを希望の数に設定することでこれを行えます。自動スレッド設定により、config.iniでThreadConfigまたはMaxNoOfExecutionThreadsの値を設定する必要がなくなります。AutomaticThreadConfigが有効になっている場合、これらのパラメータのいずれの設定も使用されません。

　この作業の一環として、ハードウェアとCPUの可用性とNDBデータノードによる使用状況に関する情報を提供する一連のテーブルがndbinfo情報データベースに追加されました。これらのテーブルとそれぞれが提供する情報の簡単な説明は、以下のとおりです。

　・cpudata：過去1秒間のCPU使用率
　・cpudata_1sec：過去20秒間の1秒あたりのCPU使用率
　・cpudata_20sec：過去400秒間の20秒間隔あたりのCPU使用率
　・cpudata_50ms：過去1秒間の50ミリ秒間隔あたりのCPU使用率
　・cpuinfo：データノードが実行されるCPU
　・hwinfo：データノードが存在するホスト上のハードウェア

　これら全てのテーブルが、NDB Clusterでサポートされている全てのプラットフォームで使用できるわけではありません。

　・cpudata、cpudata_1sec、cpudata_20sec、cpudata_50msテーブルは、LinuxとSolarisオペレーティングシステムでのみ使用可能です。
　・cpuinfoテーブルは、FreeBSDまたはMacOSでは使用できません。

● キーのルックアップとスキャンの使用を追跡するために使用されるDBLQHブロックに統計情報を追加し、DBTCとDBSPJからのクエリを追跡します。ジョブバッファキューのサイズをチェックしてスキャンする行数を決定するのではなく、負荷が高いが実際にはリアルタイムブレークごとにスキャンされる行数を減らす必要がないという状況を検出することによって、CPUの輻輳がない場合は、より多くの行をスキャンできます。これにより、高負荷を処理する時のパフォーマンスとリアルタイムの動作が改善します。

● テーブルパーティションとフラグメントを処理するための新しい方法が導入されました。これにより、特定のデータノードのローカルデータマネージャー（LDM）の数は、REDOログパーツの数とは関係なく決定でき、LDMの数は非常に可変になりました。NDBは、この作業の一部として実装されたClassicFragmentationデータノード設定パラメータがfalseに設定されている時に、この方法を使用します。これが行われると、LDMの数は、データノードごとにテーブルに作成するパーティションの数を決定するためにもう使用されません。代わりに、このリリースで導入されたPartitionsPerNodeパラメータがこの数を決定するようになりました。これは、テーブルが持つべきフラグメントの数を計算するために使用されます。

　ClassicFragmentationのデフォルト値がtrueの場合、LDMの数を使用する従来の方法が使用され、テーブルが持つべきフラグメントの数を決定します。

■ バグ修正

● macOS：Mac OS X用のNDBをビルドする時に発生した多くのコンパイラ警告を削除しました。（バグ #31726693）

● Microsoft Windows：storage\ndb\src\kernel\blocks\dbacc\dbaccmain.cppにあるVisual Studio 2013から、コンパイラの警告 C4146: unary minus operator applied to unsigned type, result still unsigned を削除しました。（バグ #23130016）

● Solaris：ソースレベルのエラーが原因で、atomic_swap_32()は指定されているはずでしたが、実際にはNDB ClusterのSolarisビルドには使用されませんでした。（バグ #31765608）

● NDBレプリケーション：RESET REPLICA ALL／RESET SLAVE ALLの発行後、NDBはレプリカが再起動したことを検出できませんでした。（バグ #31515760）

● NDB Cluster API：NdbDictionaryおよびNDB APIの関連する内部クラスの実装におけるstrlen()の冗長な使用法を削除しました。（バグ #100936、バグ #31930362）

● MySQL NDB ClusterJ：DomainTypeHandlerがSessionFactoryによってインスタンス化されると、それは静的マップtypeToHandlerMapにローカルに格納されていました。データノードへの個別の接続用の複数の異なるSessionFactoriesがClusterJアプリケーションによって取得された場合、静的なtypeToHandlerMapはそれら全てのファクトリによって共有されます。SessionFactoriesの1つが閉じられると、それが作成した接続が閉じられ、その接続によって開かれた全てのテーブルがNDB APIグローバルキャッシュからクリアされました。ただし、typeToHandlerMapはクリアされず、それを介して、他のSessionFactoriesは既にクリアされているテーブルのDomainTypeHandlerにアクセスし続けます。これらの廃止されたDomainTypeHandlerには、無効なNdbTable参照が含まれており、これらのテーブル参照を使用したndbapi呼び出しはエラーになりました。

　このパッチは、SessionFactoryが閉じられた時にそれらがクリアされるように、typeToHandlerMapおよびそれに関連するproxyInterfacesToDomainClassMapマップをSessionFactoryに対してローカルにすることによって、この問題を修正します。（バグ #31710047）

● MySQL NDB ClusterJ：com.mysql.clusterj.connection.pool.size=0を設定すると、NDB Clusterへの接続が失敗しました。この修正により、com.mysql.clusterj.connection.pool.size=0を設定すると、期待どおりに接続プールが無効になり、SessionFactoryを要求する度に新しいファクトリが作成されるようになり、同じ接続文字列を使用してクラスターへの個別の接続が作成されます。（バグ #21370745、バグ #31721416）

● disk_page_abort_prealloc()を呼び出すと、この内部関数からのコールバックは無視されるため、LQHKEYREQシグナルの操作レコードの削除は待機せずに続行されます。これにより、コールバックが完了する前にテーブルが削除される可能性があり、ページがディスクから取得されるとPGMANでエラーが発生しました。

　これを回避するために、我々は、特にこのページキャッシュミスのために、テーブルの使用カウントを追加します。このカウントは、ページキャッシュミスが戻るとすぐに減少します。これは、ディスク読み取りから戻った時にテーブルがまだ存在していることを我々が保証することを意味します。（バグ #32146931）

● インデックス統計でサポートされているインデックスキーの最大サイズ（3056バイト）を使用すると、データノードでバッファの問題が発生しました。（バグ #32094904）

　参照：バグ #25038373。

● NDBは、CLOCK_MONOTONICを優先するようになりました。これは、Linuxでは周波数変更によって調整されますが、一時停止中には更新されません。MacOSでは、NDBは同じCLOCK_UPTIME_RAWを代わりに使用しますが、調整の影響を受けない点が異なります。

　さらに、NdbConditionを初期化すると、使用する単調クロックは、NdbTickによって使用されるのと同じプリプロセッサロジックを再実行するのではなく、NdbTickから直接取得されます。（バグ #32073826）

● ndb_restoreは、ビッグエンディアンシステムで--decryptオプションを指定して実行すると、予期せず終了しました。（バグ #32068854）

● データノードの受信スレッドが、ジョブバッファがいっぱいで受信できないことを検出した場合、次のチェック時に、以前に停止したのと同じポイントでトランスポーターからの受信を再開することを保証するために何も行われませんでした。（バグ #32046097）

● メタデータチェックは、ndb_restoreツールを使用して復元されたテーブルの自動同期中に失敗しました。これはインデックスに関連するタイミングの問題であり、自動同期用のテーブルが選択された時に発生した次の2つのシナリオで見つかりました。

　a. インデックスがNDBディクショナリにまだ作成されていない場合
　b. インデックスが作成されたが、まだ使用できなかった場合

　（バグ #32004637）

● 影響を受けるカーネルブロックと、この情報を毎回検索するのではなくデータ構造内の各ブロックに対して呼び出す必要のある送信関数を登録することにより、パックされた信号の送信を最適化しました。（バグ #31936941）

● 2つのデータ定義言語ステートメント（1つはデータベース上、もう1つは同じスキーマ内のテーブル上）が並行して実行された場合、デッドロックが発生する可能性がありました。データベースに影響を与えるDDLステートメントは、最初にグローバルスキーマロックを取得しましたが、それがデータベースのメタデータロックを取得する前に、テーブルに影響を与えるステートメントが、スキーマのインテンション排他メタデータロックを取得しました。したがって、テーブルDDLステートメントはグローバルスキーマロックがテーブルのメタデータロックを排他ロックにアップグレードするのを待っていましたが、データベースDDLステートメントはデータベースの排他メタデータロックを待っていたため、デッドロックが発生しました。

　テーブルスペースとテーブルに関する同様のタイプのデッドロックが発生することは既に知られていました。NDBは既にその問題を検出し、解決しました。現在の修正では、そのロジックがデータベースとテーブルも処理するように拡張されており、その問題を解決しています。（バグ #31875229）

● Clang 8は、初期化されていない変数が原因で警告を出しました。（バグ #31864792）

● 挿入のために取得された空のページは、ログシーケンス番号を受け取りませんでした。これは、ページが以前に使用されていたため、再度使用される前にログの取り消しを実行する必要がある場合に必要です。（バグ #31859717）

● 完全に複製されたテーブルに対してインプレースのALTER TABLE ... ADD PARTITIONステートメントを実行する試みを拒否する場合、理由が提供されませんでした。（バグ #31809290）

● マスターノードが、再起動に失敗したノードの起動よりも新しいGCIを記録した場合、後者の後続の再起動は、指定されたGCIを復元できなかったため、実行できませんでした。（バグ #31804713）

● 3つまたは4つのフラグメントレプリカを使用する場合、一度に複数のノードを追加できます。つまり、DBLQHとDBDIHは、1つだけではなく、最大3つまでの異なるフラグメントレプリカの数に基づいてディストリビューションキーを持つことができます（つまり、MAX_REPLICAS - 1）。（バグ #31784934）

● DBLQHでは、次のローカルクエリハンドラからLQHKEYREF信号を受信する前に、ABORT信号がDBTCから到着する可能性がありました。現在、このような場合、アウトオブオーダーのABORT信号は無視されます。（バグ #31782578）

● NDBは、ALTER TABLE ... COMMENT="..."ステートメントがALGORITHM=COPYを指定しないケースを正しく処理しませんでした。（バグ #31776392）

● 場合によっては、フラグメントのUNDOログのエンドポイントを見逃す可能性がありました。（バグ #31774459）

● ndb_print_sys_fileは、NDB 8.0.18で導入されたsysfile形式のバージョン2で、正しく機能しませんでした。（バグ #31726653）

　参照：バグ #31828452。

● DBLQHは、同じトランザクションIDを持つ同一の操作レコードが異なるトランザクションコーディネーターからのものである場合を処理できませんでした。これにより、ノード障害後もロックされた行が存続し、ノードのリカバリが完了しなくなりました。（バグ #31726568）

● DBDIHは、指定されたIDを持つローカルチェックポイントを受信して復元しますが、実際には代わりに後のLCPが使用される可能性があります。しかし、そのような場合に部分LCPを実行すると、DIHブロックは使用されたLCPのIDと完全に同期されませんでした。（バグ #31726514）

● ほとんどの場合、ハッシュインデックスを検索する時は、行はプライマリキーを読み取るために使用されますが、行がまだコミットされていない時は、プライマリキーをコピー行から読み取ることができます。行は削除されると、プライマリキーの読み取りに使用できなくなります。以前は、このような場合、プライマリキーはNULLとして扱われていましたが、これにより、初期化されていないデータを使用して比較が行われる可能性がありました。

　現在これが発生すると、行が削除されていない場合にのみ比較が行われます。それ以外の場合は、シリアルキュー内の操作間で行がチェックされます。プライマリキーを持つ操作がない場合、並列キューのエントリは行を再挿入できないため、いかなる比較も等しくないと報告される可能性があります。シリアルキューのエントリが挿入である場合、同じ主キーを2回挿入できないように、この操作の主キーをそのように識別する必要があるという事実のために、これを確認する必要があります。（バグ #31688797）

● REDOログレコードの書き込みと同様に、グローバルチェックポイントレコードの書き込みに現在使用されているファイルがいっぱいになると、書き込みは次のファイルに切り替わります。この切り替えは、新しいファイルが実際にレコードを受信する準備ができるまで発生しないはずですが、これが当てはまることを確認するためのチェックは行われませんでした。これにより、ndb_restoreを使用してバックアップからデータを復元する予定外のデータノードシャットダウンが発生する可能性がありました。（バグ #31585833）

● DBSPJブロックで不要になった共有グローバルメモリの解放が、以前よりも迅速に行われるようになりました。（バグ #31321518）

　参照：バグ #31231286。

● kill -9を使用して単一ノードグループにある4つのうち3つのノードを停止すると、予定外のクラスターシャットダウンが発生しました。このような状況でこれが発生しないようにするために、現在は、NDBは、ノード障害が発生していないノードグループがアービトレーションチェックによって完全に実行可能であると見なされるようにします。（バグ #31245543）

● マルチスレッドのインデックスビルドは、それらに対して許可されていない内部関数を使用しようとする場合がありました。（バグ #30587462）

● クラスタに新しいデータノードを追加している時、および、管理ノードが更新された設定ファイルを使用して再起動されている時に、一部のデータノードがエラー virtual void TCP_Transporter::resetBuffers(): Assertion `!isConnected()' failed で予期せず終了しました。（バグ #30088051）

● foreign_key_checksが0に設定されている外部キーの親テーブルに対してTRUNCATE TABLEまたはDROP TABLEを実行できませんでした。（バグ #97501、バグ #30509759）

● 内部のNdbReceiver::unpackNdbRecord()メソッドを最適化しました。これは、データノードから取得された行をパックされたワイヤー形式からNDB API行形式に変換するために使用されます。変更前は、結合を実行するためのCPU使用率の約13％がこのメソッド内で発生していました。これは約8％に減少しました。（バグ #95007、バグ #29640755）

MySQL NDB Cluster 8.0.23リリースノート（MySQLウェブサイト）： https://dev.mysql.com/doc/relnotes/mysql-cluster/8.0/en/news-8-0-23.html

---