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

主な変更点

■ コンパイル関連

● NDBは、Ubuntu 21.10でGCC 11を使用してコンパイルしませんでした。（バグ #33424843）

■ 追加・変更された機能

● NDBインデックス統計に関する非常に基本的な情報を提供するndbinfo index_statsテーブルを追加しました。これは主に内部テストでの使用を目的としていますが、ndb_index_statやその他のツールと組み合わせて使用すると役立つ場合があります。（バグ #32906654）
　以前は、ndb_importは常に、読み取られているCSVファイルの名前から派生した名前のテーブルにデータをインポートしようとしました。このリリースでは、このプログラムに--tableオプション（短縮形：-t）が追加されています。これは、この動作をオーバーライドし、ターゲットテーブルの名前を直接指定します。（バグ #30832382）

■ バグ修正

● 重要な変更：非推奨のデータノードオプション --connect-delayは削除されました。このオプションは、--connect-retry-delayの同義語でしたが、全ての場合に適用されるわけではありませんでした。この問題は修正され、このオプションは正しく機能するようになりました。さらに、このオプションの短縮形 -rは非推奨になり、将来のリリースで削除される予定です。（バグ #31565810）
　参照：バグ #33362935。
● Microsoft Windows：Windowsで、MySQLサーバー（商用）およびMySQL NDB Cluster（商用およびコミュニティ）用に不足しているデバッグおよびテストスイートのバイナリを追加しました。（バグ #32713189）
● NDBレプリケーション：mysqldオプション --slave-skip-errorsを使用すると、レプリケーションアプライヤーのSQLスレッドが特定の番号のエラーを自動的にスキップできるようになります。バイナリログのトランザクション全体が適用されないためにレプリカが分岐する可能性があるので、これは本番環境では推奨されません。エポックトランザクションを使用するNDBCLUSTERの場合、これにより、変更のエポック全体が適用されず、データの一貫性が失われる可能性があります。
　Ndbは、適用されたエポックのシーケンスもチェックし、シーケンスに問題がある場合はエラーでレプリカアプライヤーを停止します。--slave-skip-errorsが使用されていて、エラーがスキップされた場合、これによりエポックトランザクション全体がスキップされます。これは、エポックトランザクションを適用しようとする後続の試行で検出され、その結果、レプリカアプライヤーSQLスレッドが停止します。
　このリリースでは、新しいオプション --ndb-applier-allow-skip-epochが追加され、ユーザーは完全にスキップされたエポックトランザクションを無視できるようになり、他のMySQLストレージエンジンと同様に --slave-skip-errorsオプションを使用できるようになりました。これは、本番環境の設定ではなく、テストでの使用を目的としています。これらのオプションの使用は完全に自己責任で行ってください。
　mysqldが（--slave-skip-errorsとともに）新しいオプションを使用して開始される場合、欠落しているエポックが検出されると警告が生成されますが、レプリカアプライヤーSQLスレッドは引き続き適用されます。（バグ #33398973）
● NDBレプリケーション：ndb_apply_statusテーブルのlog_name列は、latin1文字セットを使用して、VARCHARとして定義されているにもかかわらず、VARBINARYとして作成されました。そのため、一部のツールを使用してテーブルにクエリを実行すると、16進デコードされた出力が発生しました。
　mysqldがndb_apply_statusテーブルのレイアウトをチェックする時に、ndb_apply_statusで障害のある列タイプを検出し、NDBへの接続中にテーブル定義をデータディクショナリに再インストールすることにより、これを修正します。（バグ #33380726）
● NDB Cluster API：いくつかの新しい基本的な例 C++ NDB APIプログラムが、ソースツリーのstorage/ndb/ndbapi-examples/ndbapi_basic/の下のディストリビューションに追加されました。これらは短くて、既存のAPIの例よりもNDB APIの初心者にとって理解しやすいはずです。また、最近のC++標準とプラクティスにも準拠しています。これらの例は、NDB APIドキュメントにも追加されています。（バグ #33378579、バグ #33517296）
● NDB Cluster API：DIVERIFYREQシグナルを非同期で使用することはできなくなりました。（バグ #33161562）
● batched_key_accessオプティマイザスイッチが有効になっている場合、NDBテーブルでの同じプッシュ結合が誤った結果を返しました。
　この問題は次のように発生しました。バッチキーアクセス（BKA）アルゴリズムを使用して2つのテーブルを結合すると、バッチキーのセットがテーブルの1つから最初に収集されます。マルチレンジ読み取り（MRR）操作は、他に対して構築されます。境界（範囲）のセットは、バッチキーを使用して各境界を構築することにより、MRRで指定されます。
　結果の行が返される時、返された各行がどの範囲から来ているかを識別する必要があります。これは、BKA結合を実行する外部テーブル行を識別するために使用されます。問題のMRR操作がプッシュされた結合操作のルートである場合、SPJはこの識別子（RANGE_NO）を取得できませんでした。プッシュされた結合クエリからそのようなRANGE_NOを返すために欠落しているSPJ API機能を実装することにより、これを修正します。（バグ #334716308）
● オンライン再編成中のスキャンログ出力の待機タイミングが正しく実行されませんでした。この修正の一環として、定期的な更新を提供するために、無期限にスケーリングするのではなく、10秒ごとに1つのメッセージを生成するようにタイミングを変更します。（バグ #35523977）
● ndbdとndbmtdに欠測値チェックを追加しました。（バグ #33661024）
● オンラインテーブル再編成は、テーブルのフラグメントの数を増やし、それらの間で行を移動します。これは、次の手順で実行されます。
　　a. 行を新しいフラグメントにコピーします
　　b. ディストリビューション情報（ハッシュマップ数とフラグメントの総数）を更新します
　　c. 古いディストリビューションを使用したスキャンアクティビティが停止するのを待ちます
　　d. 既存のパーティションから移動した行を削除します
　　e. 古いハッシュマップへの参照を削除します
　　f. ステップ2以降に開始されたスキャンアクティビティが停止するのを待ちます
　カウンティングエラーのため、ステップ6で再編成がハングする可能性がありました。スキャン参照カウントはデクリメントされなかったため、期待どおりにゼロに達することはありませんでした。（バグ #33523991）
● USING HASHを使用して作成されたUNIQUEインデックスは、順序付けられたアクセス操作または範囲アクセス操作をサポートしていませんが、完全なキーが指定されているそれらの操作のみをサポートしており、最大で1行を返します。それでも、NDBテーブルのそのようなインデックスでは、範囲アクセスが引き続きインデックスで使用されていました。（バグ #33466554、バグ #33474345）
● ndinfo.index_statsテーブルに対する各クエリは、NdbRecordをリークしました。コンテキストを変更して、作成するNdbRecordオブジェクトを所有し、スコープ外になった時にNdbRecordを解放することによって、そして、コンテキストごとに1つだけのレコードの作成をサポートすることによって、これを修正します。（バグ #33408123）
● 変更された行でキャッシュされたテーブルの統計を更新する時に同時実行性の問題が発生しました。複数のスレッドが同じテーブルを更新する時、それらのスレッドはキャッシュされた行数を更新するためにNDB_SHAREミューテックスを競合しました。
　これを修正するために、ミューテックスを取得して実際の共有値を更新しようとするのではなく、アトミックカウンターを使用して変更された行のストレージを再実装します。これにより、スレッドをシリアル化する必要が少なくなります。さらに、キャッシュから統計を削除する場合にのみ、変更された行の数を行数に追加し、キャッシュされた統計のみを保護する個別のミューテックスを提供するようになりました。（バグ #33384978）
　参照：バグ #32169848。
● コーディネーターがスキーマイベントを受信した時にスキーマディストリビューションクライアントがスキーマオブジェクトを解放する前にタイムアウトを検出した場合、コーディネーターは古いスキーマイベントを返すのではなく処理しました。
　コーディネーターは、スキーマディストリビューションタイムアウトがクライアントによって検出されたかどうかを知らずに、スキーマオブジェクトが有効になるとすぐにスキーマイベントの処理を開始しました。これを修正するために、スキーマオブジェクトの状態を示し、クライアントがスキーマディストリビューションタイムアウトを検出した時およびスキーマイベントがコーディネーターによって受信された時にその状態を変更します。これにより、コーディネーターとクライアントの両方がこれを認識し、同期されたままになります。（バグ #33318201）
● MySQLオプティマイザは、handler::read_cost()とCost_model::page_read_cost()の2つの異なるメソッドを使用して、異なるアクセスメソッドのコストを見積もりますが、これらによって返されるコスト値は必ずしも比較可能ではありませんでした。場合によっては、これにより、間違ったインデックスが選択され、影響を受けるクエリの実行時間が長くなりました。NDBのこれを修正するためには、オプティマイザのpage_read_cost()メソッドをNDBCLUSTERに固有のメソッドでオーバーライドします。この問題に取り組んでいる時に、NDBハンドラーがread_cost()で使用されるread_time()メソッドを実装していないこともわかりました。このメソッドはha_ndbclusterによって実装されるようになりました。そのため、オプティマイザーは、順序付けされたインデックス（範囲スキャン）ではなく一意キーを使用する時に、NDBのコスト差を適切に考慮できるようになりました。（バグ #33317872）
● クエリ用にNDBテーブルを開く時、オプティマイザが最適なクエリプランを選択できるように、インデックス統計が取得されます。統計にアクセスする各クライアントは、統計にアクセスする前と後の両方で、グローバルインデックス統計ミューテックスを取得します。これにより、同じテーブルで動作しているクエリがあるかどうか、または異なるテーブルで動作しているクエリがあるかどうかに関係なく、クエリのパフォーマンスに影響を与えるミューテックスの競合が発生します。
　アトミックカウンターでインデックス統計参照の数を保護することで、これを修正します。32を超えるクライアントでベンチマークを行った場合、追加のクライアントでスループットが向上しなかった場合、問題は明確にわかりました。この修正により、スループットは最大64クライアントで拡張され続けます。（バグ #33317320）
● 場合によって、イベントのカテゴリが適切に検出されませんでした。（バグ #33304814）
● ndbdを実行しているデータノードを持つ既存のクラスターに、ndbdを実行している新しいデータノードを追加することはできませんでした。（バグ #33193393）
● NDB_STORED_USER権限を付与されたユーザーについて、SQLノードが再起動される度にmysql.userテーブルのpassword_last_changed列が更新されました。（バグ #33172887）
● DBDICTは、テーブル名のチェックを常に正しく実行するとは限りませんでした。（バグ #33161548）
● ndbdおよびndbmtdにいくつかの欠落しているIDおよびその他の値のチェックを追加しました。（バグ #33161486、バグ #33162047）
● ndbdおよびndbmtdにいくつかの欠落しているIDおよびその他の値のチェックを追加しました。（バグ #33161259、バグ #33161362）
● SET_LOGLEVELORDシグナルは、常に正しく処理されるとは限りませんでした。（バグ #33161246）
● DUMP 11001は、常に全てのその引数を正しく処理するとは限りませんでした。（バグ #33157513）
● ファイル名は常に正しく検証されるとは限りませんでした。（バグ #33157475）
● データノードにいくつかの欠落しているチェックを追加しました。 （Bug＃32983723、Bug＃33157488、Bug＃33161451、Bug＃33161477、Bug＃33162082）
● ndbdおよびndbmtdにいくつかの欠落しているIDおよびその他の値のチェックを追加しました。（バグ #32983700、バグ #32893708、バグ #32957478、バグ #32983256、バグ #32983339、バグ #32983489、バグ #32983517、バグ #33157527、バグ #33157531、バグ #33161271、バグ #33161298、バグ #33161314、Bug ＃33161331、バグ #33161372、バグ #33161462、バグ #33161511、バグ #33161519、バグ #33161537、バグ #33161570、バグ #33162059、バグ #33162065、バグ #33162074、バグ #33162082、バグ #33162092、バグ #33162098、バグ #33304819）
● 管理サーバーは、間違ったサイズのイベントを常に正しく処理するとは限りませんでした。（バグ #32957547）
● --config-fileオプションを指定せずにndb_mgmdが起動される場合、ユーザーは、同じクラスター内の別の管理サーバーに接続文字列を提供する必要があります。これにより、起動中の管理サーバーが他のサーバーから設定情報を取得できるようになります。接続文字列のホストアドレスを解決できなかった場合、接続を確立しようとしている時に、開始中のndb_mgmdが無期限にハングしました。
　接続の失敗が一時的なエラーとして扱われ、ndb_mgmdが接続を再試行し、その後失敗するなどの繰り返しが発生したことが理由で、この問題は発生しました。。ndb_mgmdによるホスト名解決の失敗を永続的なエラーとして扱い、すぐに終了することによって、これを修正します。（バグ #32901321）
● ndb_import --csvoptの引数で使用されるパラメータの順序は一貫して処理されるようになり、右端のパラメーターが常に優先されるようになります。これは、パラメータの重複インスタンスにも適用されます。（バグ #32822757）
● 場合によっては、バックアップの復元中にREDOログに問題が発生すると、データノードが計画外にシャットダウンすることがありました。これを修正するために、REDOログファイルが書き込みに使用できない場合、正しい待機コードと待機ログ部分をCONTINUEBシグナルに含めてから送信するようになりました。（バグ #32733659）
　参照：バグ #31585833。
● バイナリロギングスレッドは、全てのデータノードの準備が整う前に開始しようとすることがあり、不要な警告やエラーが過剰にロギングされていました。（バグ #32019919）
● 内部のNdb_table_guard::getTable()メソッドにいくつかの値チェックを導入しました。これは、NDBテーブルでALTER TABLEを実行している時にSQLノードで計画外のシャットダウンが発生するという既知の問題を修正し、潜在的に追加の問題を修正します。（バグ #30232826）
● 誤解を招くエラーメッセージを置き換え、ホスト名を解決できなかった時のndb_mgmdの動作を改善しました。（バグ #28960182）
● MySQL Enterprise MonitorがNDB Clusterのメモリ使用量を監視するために使用するクエリは、NDBテーブルの数が増えるにつれて、パフォーマンスが著しく低下しました。これを次のように修正します。
　　・バーチャルndbinfoテーブルの行数がMySQLオプティマイザで利用できるようになりました
　　・サイズ見積もりが全てのndbinfoテーブルに提供されるようになりました
　　・ほとんどの内部ndbinfoテーブルにプライマリキーが追加されました
　これらの改善を受けて、ndbinfoテーブルに対するクエリのパフォーマンスは、同等のMyISAMテーブルに対するクエリと同等になるはずです。（バグ #28658625）
● NDB 8.0.23で行われたLDMパフォーマンスの改善を受けて、UPDATE_FRAG_DIST_KEY_ORDシグナルは、ノードID 1を使用するデータノードに必要な時に送信されることはありませんでした。3つまたは4つのレプリカでクラスターを実行し、同じノードグループ内の別のノードを再起動すると、その結果、SQLステートメントがエラー ySQL 1297 ER_GET_TEMPORARY_ERRMSGで拒否され、その後、SHOW WARNINGSがエラーNDBエラー1204を報告します。
　注意
　　このリリースにアップグレードする前に、同じノードグループ内の他のノードが再起動された時は
　　いつもデータノード1を再起動することによって、この問題を回避できます。
　（バグ #105098、バグ #33460188）
● NDB 7.6からNDB 8.0へのアップグレードの一部として実行されたデータノードのローリングリスタートに続いて、データノードは強制的にシャットダウンされました。これを修正するために、LQHKEYREQシグナルをDBLQHカーネルブロックとDBSPJカーネルブロックの両方に送信できるようにします。（バグ #105010、バグ #33387443）
● AutomaticThreadConfigパラメータが有効になっている時、NumCPUはデータノードログに常に0として表示されました。さらに、このパラメータが使用されている時、スレッドのCPUバインディングが正しく行われるようになり、データノードログに各スレッドの実際のCPUバインディングが表示されます。（バグ #102503、バグ #32474961）
● ndb_blob_tool --helpが期待される出力を返しませんでした。（バグ #98158、バグ #30733508）
● NDBは、内部システムテーブルの作成およびドロップ関数からエラーを返す時に、保留中のスキーマトランザクションを閉じませんでした。

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

---