主な変更点
■ バックアップ関連
● このリリースでは、バックアップからのデータの不正なリカバリに対する保護を提供するために、AES-256-CBCを使用したNDBネイティブ暗号化バックアップのサポートが追加されています。暗号化されたバックアップファイルは、ユーザーが指定したパスワードで保護されます。NDBはこのパスワードを保存しません。これは、ユーザーまたはアプリケーションが行う必要があります。暗号化されたバックアップを作成するためには、ndb_mgm client START BACKUPコマンドでENCRYPT PASSWORD=passwordを使用します（必要な他のオプションに加えて）。MGM API ndb_mgm_start_backup4()関数を呼び出すことにより、暗号化されたバックアップをアプリケーションで開始することもできます。 暗号化されたバックアップから復元するためには、オプション--decryptと--backup-password=passwordの両方を指定してndb_restoreを使用します。ndb_print_backup_fileは、このリリースで追加された-Pオプションを使用して、暗号化されたファイルを読み取ることもできます。 この機能で使用される暗号化パスワードは、!、'、"、$、%、\、^以外の印刷可能なASCII文字の範囲から最大256文字の任意の文字列にすることができます。暗号化または復号化のためにパスワードが指定される場合、一重引用符または二重引用符を使用して引用符で囲む必要があります。''または""を使用して空のパスワードを指定することは可能ですが、これは推奨されません。 このリリースでNDB Clusterディストリビューションに追加されたndbxfrmユーティリティを使用して、既存のバックアップファイルを暗号化できます。このプログラムは、暗号化されたバックアップファイルを復号化することもできます。また、ndbxfrmは、NDB Clusterのバックアップファイルを圧縮および解凍します。圧縮方法は、CompressedBackupが有効になっている時に圧縮されたバックアップを作成するためにNDB Clusterで使用される方法と同じです。 RequireEncryptedBackupを使用して、暗号化されたバックアップを要求することもできます。このパラメータを（1に設定することにより）有効にすると、管理クライアントは暗号化されていないバックアップを実行しようとするのを拒否します。
■ 非推奨と削除関連
● NDBクライアントプログラム：このリリース以降、MySQL NDB Cluster Auto-Installer（ndb_setup.py）は非推奨になり、NDB Clusterの将来のバージョンで削除される可能性があります。（バグ #31888835） ● ndbmemcache：ndbmemcacheは、NDB Clusterのこのリリースで非推奨になり、次のリリースで削除される予定です。（バグ #31876970）
■ 追加・変更された機能
● 重要な変更：Ndb_metadata_blacklist_sizeステータス変数の名前がNdb_metadata_excluded_countに変更されました。（バグ #31465469） ● パッケージング：NDB ClusterおよびNDB Cluster Dockerイメージのserver-minimal RPMに次の改善を加えました。 ・ndb_importおよびその他の便利なユーティリティを追加しました。 ・含まれるNDBユーティリティが動的にリンクされるようになりました。 ・NDB Cluster Auto-Installerが含まれなくなりました。 ・ndbmemcacheが含まれなくなりました。 （バグ #31838832） ● NDBレプリケーション：NDB ClusterによるMySQLタイプのBLOB、MEDIUMBLOB、LONGBLOB、TEXT、MEDIUMTEXT、LONGTEXT (“Blob”)の列を含む行への更新のバッチ処理。これは、次のいずれかのタイプのINSERT、UPDATE、DELETEステートメントに影響します。 ・同じ行の複数のblob列を変更するステートメント ・同じステートメント内のblob列を含む複数の行を変更するステートメント これは、SQLまたは他のAPIノードとレプリカクラスター内のデータノードとの間で必要なラウンドトリップの数を大幅に削減することで実現されます。場合によっては、10分の1以上削減されます。 他のSQLステートメントでも、これらの改善によるパフォーマンス上の利点が見られる場合があります。このようなステートメントには、1つ以上のBlob列を含むテーブルを操作する場合のLOAD DATA INFILEおよびCREATE TABLE ... SELECT ...が含まれます。さらに、以前にNDB以外を使用し、1つ以上のBlob列を含むテーブルのストレージエンジンを変更するALTER TABLE ... ENGINE = NDBステートメントも、この拡張機能が実装される前よりも効率的に実行される可能性があります。 Blob列を更新する一部のSQLステートメントのパフォーマンスは、バッチ処理を分割するテーブルBlob列のスキャンを必要とするため、この機能拡張によって著しく改善されることはありません。このようなステートメントには、次のタイプのステートメントが含まれます。 ・Blobタイプを使用するプライマリキー列または一意キー列で照合することによって行をフィルタリングするSELECT ・一意の値に依存しないWHERE条件を使用したUPDATEまたはDELETE ・ステートメントを実行する前にNDBストレージエンジンを既にに使用しているテーブルへのALTERTABLEステートメントのコピー タイプ TINYBLOBまたはTINYTEXT（または両方）の列のみを変更するステートメントは、この拡張機能の影響を受けません。 この改善を最大限に活用するためには、slave_allow_batchingを有効にする必要があります。また、エポックトランザクションを適用するためにレプリカクラスタに必要とされるラウンドトリップの数を最小限に抑えるために、--ndb-batch-sizeおよび--ndb-blob-write-batch-bytesのMySQLサーバーオプションで使用される値を増やすことをお勧めします。（バグ #27765184） ● NDBユーティリティとndbclientの動的リンクを可能にするために、CMakeオプション NDB_UTILS_LINK_DYNAMICが追加されました。（バグ #31668306） ● SQLノードを使用した管理ノードとデータノード間の接続を含む、管理ノードとデータノードへの接続でIPv6アドレッシングがサポートされるようになりました。IPv6アドレッシングが機能するためには、クラスタがデプロイされているオペレーティングプラットフォームとネットワークがIPv6をサポートしている必要があります。IPv6アドレスへのホスト名解決は、オペレーティングプラットフォームによって提供される必要があります（これは、IPv4アドレッシングを使用する場合と同じです）。 同じクラスター内でIPv4アドレスとIPv6アドレスを混在させることは推奨されませんが、--bind-addressがndb_mgmdで使用されていない場合は、次のいずれかの場合に機能させることができます。 ・IPv6で設定された管理ノード、IPv4で設定されたデータノード：これは、データノードが管理ノードのIPv4アドレスに設定された--ndb-connectstringで開始されている場合に機能します。 ・IPv4で設定された管理ノード、IPv6で設定されたデータノード：これは、データノードが管理ノードのIPv6アドレスに設定された--ndb-connectstringで開始されている場合に機能します。 IPv6アドレッシングをサポートしていないNDBのバージョンからサポートしているバージョンにアップグレードする場合、ネットワークがIPv4とIPv6の両方を既にサポートしている必要があります。ソフトウェアのアップグレードを最初に実行する必要があります。この後、config.ini設定ファイルで使用されているIPv4アドレスを希望のIPv6アドレスで更新できます。最後に、設定の変更を有効にするために、クラスタのシステム再起動を実行します。
■ バグ修正
● 重要な変更; NDB Cluster API：Node.js用のNDB Clusterアダプターは、廃止されたバージョンのランタイムに対して作成されました。現在は、Node.js 12.18.3を使用して作成されており、そのバージョン以降のバージョンのNode.jsのみがNDBでサポートされています。（バグ #31783049） ● 重要な変更：除外されたメタデータオブジェクトを同期するためには、根本的な問題がある場合はそれを修正し、その後オブジェクトの同期を再度トリガーする必要がありました。これは、個々のテーブルの発見を通して実現できますが、テーブルとSQLノードの数が増えると拡張性が低下します。SQLノードをクラスターに再接続することによって実行することも可能ですが、そうすると余分なオーバーヘッドが発生します。 この問題を修正するために、ndb_metadata_syncがユーザーによって有効にされると、同期の失敗により除外されたデータベースオブジェクトのリストがクリアされます。これにより、そのような全てのオブジェクトが後続の検出実行で同期の対象になり、除外された全てのオブジェクトの同期の再試行が簡単になります。 この修正により、以前は各検出実行の開始時に行われていた、再試行されるオブジェクトの検証も削除されます。これらのオブジェクトはndb_metadata_syncが有効になっている間のみ対象となるため、この変数が無効になっていると、再試行されるオブジェクトのリストがクリアされ、全ての変更が同期されたことを通知します。（バグ #31569436） ● パッケージング：NDB Clusterに含まれているDojoライブラリーがバージョン1.15.4にアップグレードされました。（バグ #31559518） ● NDBディスクデータ：ndbmtdは、復元操作中にログファイルグループのルックアップを完了できなかった時に、予期せず終了することがありました。（バグ #31284086） ● NDBディスクデータ：テーブルスペースをいっぱいにするのに十分なディスクデータオブジェクトを作成した後、3つまたは4つのレプリカを持つクラスタをアップグレードしている間に、および、ディスクデータテーブルで挿入を実行している間に、一部のデータノードを停止しようとすると、他のノードが正しく終了しませんでした。（バグ #30922322） ● NDBレプリケーション：Unixベースのオペレーティングシステムでは、SIGHUPシグナルをサーバーに送信することによってバイナリログはフラッシュされることが可能ですが、NDBCLUSTERはSQLステートメント FLUSH、RESET、またはSHOW BINLOG EVENTSのいずれかのみを予期していました。（バグ #31242689） ● NDB Cluster API：blobを使用してNDB APIメソッド呼び出しの無効なシーケンスを作成することが可能でした。これは、一部のメソッド呼び出しがBLOBパーツやその他の問題を処理するために暗黙的にトランザクション実行をインラインで引き起こしたためです。これにより、保留中のユーザー定義BLOB操作がまだある間に、BLOBに関連する操作を実行するメソッドを使用することが原因で、ユーザー定義操作が正しく処理されない可能性がありました。現在このような場合、NDBは新しいエラー 4558 Pending blob operations must be executed before this call を発生させます。（バグ #27772916） ● ndb_restore --remap-columnは、NULL値を含む列を正しく処理しませんでした。現在は、このオプションで使用されるマッピング関数によって指定されたオフセットはNULLに適用されず、そのため、NULLは期待どおりに保持されます。（バグ #31966676） ● 8.0.18より前のバージョンのNDB Clusterから新しいバージョンにアップグレードした後、sysfileの書き込みとそれからの読み戻しが正しく機能しない場合がありました。これは、データノードへの明示的なノードグループ割り当てが（NodeGroupパラメーターを使用して）行われた場合に発生する可能性がありました。ノードグループ割り当てが自発的に変更される可能性があり、設定ファイルで参照されていないノードグループが追加される可能性もありました。これは、NDB 8.0.18で導入されたバージョン2のsysfile形式の問題が原因でした。（バグ #31828452） 参照：バグ #31726653。 ● NodeGroup=65536を使用する設定ファイルでデータノードに遭遇した後、管理サーバーは、明示的なNodeGroup設定がないデータノードをノードグループに割り当てるのを停止しました。（バグ #31825181） ● データノードは、実際には通常はシステムページサイズ（プラットフォームに応じて4096バイトまたは8192バイト）に合わせられている場合に、ページが32KBに合わせられているという無効な仮定により、PGMANカーネルブロックで致命的なメモリ破損が発生する場合がありました。（バグ #31768450、バグ #31773234） ● NDB 8.0.20で導入されたスペルミスの定義を修正しました。これにより、適応できるスピニングを制御するために使用される内部関数が動作しなくなりました。（バグ #31765660） ● UNDOログの回復中にUNDOログレコードを実行すると、ページキャッシュミスが発生した時に、前のUNDOログレコードを複数回使用する可能性がありました。（バグ #31750627） ● コーディネーターが参加者をまだ待機している間に、SQLノードまたはクラスタのシャットダウンがスキーマ配布中に発生した場合、スキーマ配布は途中で中止されましたが、このスキーマ操作に関連するndb_schema_resultの行はクリアされませんでした。これにより、同じスキーマ操作IDを持つDDL操作が同じノードIDを使用するクライアントから生じた場合、これらの行が参加者からの将来の応答と競合する可能性が残りました。 これが発生しないようにするために、NDBバイナリログのセットアップ中にndb_schema_resultのそのような全て行をクリアするようになりました。これにより、進行中のDDL配布がなく、ndb_schema_resultテーブルに残っている行が既に使われなくなったことが保証されます。（バグ #31601674） ● MySQL Cluster Auto-Installerからのヘルプ出力に誤ったバージョン情報が表示されました。（バグ #31589404） ● 特定のまれな状況では、NDBがローカルチェックポイントの完了の確認を見落とし、それは未完了のままになりました。これにより、後続のローカルチェックポイントが実行できなかったことを意味します。（バグ #31577633） ● データ定義ステートメントには、テーブルからの複数の行の読み取りまたは書き込み（またはその両方）が含まれる場合があります。NDBCLUSTERは、これらの操作を実行するためにNdbTransactionを開始します。このようなステートメントがロールバックされると、NDBCLUSTERは、NdbTransactionをロールバックして閉じる前に、スキーマの変更をロールバックしようとしました。これにより、クラスタがスキーマの変更をロールバックできる前にNdbTransactionオブジェクトが閉じるのを待っている間、ロールバックが無期限にハングしました。 現在このような場合には、NDBCLUSTERは、変更に関連付けられた開いているNdbTransactionをロールバックして閉じた後にのみ、スキーマの変更をロールバックします。（バグ #31546868） ● NDB_STORED_USER権限が新しいユーザーに付与された時に、新しいユーザーの追加が全てのSQLノードに正しく同期されるとは限りませんでした。（バグ #31486931） ● QMGRが競合するNDBエンジンとMySQLサーバーのバージョン情報を返す場合があり、それは計画外の管理ノードのシャットダウンにつながる可能性がありました。（バグ #31471959） ● 起動中のノード上のSUMAは、送信された全てのSUMA_HANDOVER_REQ信号が応答してSUMA_HANDOVER_CONF信号を送信し、SUMA_HANDOVER_CONFの受信時にセットアップされた全てのスイッチオーバーバケットがスイッチオーバーを完了するまで、マスターノードのDICTブロックにDICT_UNLOCK_ORD信号を送信すべきではありません。NoOfReplicas > 2を使用し、グローバルチェックポイント間の遅延が異常に短い特定のまれなケースでは、一部のスイッチオーバーバケットは、他のバケットよりも先にハンドオーバーの準備ができており、これが当てはまる場合でもハンドオーバーを続行することができました。（バグ #31459930） ● インデックスまたは列の順序がテーブルの順序と異なるプライマリキーを使用してNDBテーブルからデータを読み取る場合は、属性IDマッピングを実行する必要があります。一意のインデックスの場合、キャッシュされた属性IDマップはテーブルが開かれた時に作成され、その後の各読み取りに使用されますが、プライマリキーの読み取りの場合、マップは読み取りごとに作成されます。これは、プライマリキーの属性IDマップがテーブルを開く時に作成およびキャッシュされ、以降の読み取りで必要になる度に使用されるように変更されています。（バグ #31452597） 参照：バグ #24444899。 ● 復元プロセスの様々なフェーズで、ndb_restoreは一時的なエラーに対して再試行の様々な回数を使用し、再試行間で様々なスリープ時間を使用しました。これは、全ての復元フェーズで一貫した再試行回数とスリープ時間を実装することによって修正されています。（バグ #31372923） ● NDBCLUSTERをClang10でコンパイルする時に生成される警告を削除しました。（バグ #31344788） ● SPJブロックには、LQHKEYREQ信号の生成時に使用される負荷調整メカニズムが含まれています。これらがスキャンからの親の行から生成され、このスキャンにキールックアップを実行する複数の子を持つbushyトポロジがある場合、LQHKEYREQ信号が多すぎるとジョブキューがオーバーロードし、ジョブバッファがいっぱいになるためにノードがシャットダウンする可能性がありました。この問題は元々はバグ #14709490によって修正されました。この問題をさらに調査したところ、SPJクエリがbushyでなくても、ジョブバッファがいっぱいになるエラーが発生する可能性があることがわかりました。SCAN_FRAGREQシグナルをSPJブロックに送信する時に複数のフラグメントの使用を実装するために行われる作業の一部として、NDB 7.6.4のSPJワーカーの内部バッチサイズが増加することが原因で、単純なクエリでさえ、比較的少数のそのようなクエリが並行して実行された場合に、ジョブバッファをいっぱいにする可能性がありました。 この問題を修正するために、特定のリクエストの未処理のシグナルの数が256を超えると、それ以上LQHKEYREQシグナルを送信しなくなりました。代わりに、LQHKEYREQが生成される親の行がバッファリングされ、この行の相関IDが操作のコレクションに格納されて、後で再開されます。（バグ #31343524） 参照：この問題は、バグ #14709490のリグレッションです。 ● MaxDiskWriteSpeedOwnRestartは、ノードの再起動中のローカルチェックポイント書き込みの上限として受け入れられませんでした。（バグ #31337487） 参照：バグ #29943227。 ● 特定のまれな状況では、NDBテーブルのDROP TABLEがアサートをトリガーしました。（バグ #31336431） ● ノードの再起動中、起動しているノードのSUMAブロックは、既に実行中のノードからサブスクリプション（サブスクライバーのあるイベント）とサブスクライバー（実行中のNdbEventOperationインスタンス）のコピーを取得しなければなりません。コピーが完了する前、まだ起動しているノードは、ユーザーレベルのSUB_STARTまたはSUB_STOPリクエストを無視します。コピーが完了した後は、そのようなリスエストに参加することができます。コピー操作の進行中、ユーザーレベルのSUB_STARTおよびSUB_STOPリクエストは、DICTロックを使用してブロックされます。 ロックが要求された後、ロックが付与される前に、起動しているノードがSUB_STARTおよびSUB_STOPリクエストに参加でき、その結果、SUB_STARTおよびSUB_STOPリクエストが失敗するという問題が見つかりました。この修正により、DICTロックが実際に付与された後まで、ノードがこれらのリクエストに参加できないようになります。（バグ #31302657） ● ファイルシステムがO_DIRECTで実行されていて、データファイルの書き込みがO_DIRECTの書き込みで使用される512バイトのブロックサイズと一致していない場合、バックアップはFsErrInvalidParametersでエラーになりました。データファイルの合計フラグメントサイズがO_DIRECTブロックサイズと一致しない場合、NDBは最後の書き込みを必要なサイズにパディングしますが、書き込むフラグメントがない場合、BACKUPはヘッダーとフッターのみをデータファイルに書き込みました。ヘッダーとフッターが512バイト未満であるため、O_DIRECT書き込みで問題が発生します。 これは、データファイルを閉じる時にEMPTY_ENTRYを使用して、必要に応じて汎用フッターを512バイトにパディングすることで修正されます。（バグ #31180508） ● 受信したキー行を後で使用するためにバッファリングすることを要求する実行戦略を採用する場合、DBSPJはバッファメモリ割り当てツリーノードをツリーノードごとに管理するようになりました。その結果、DBSPJブロックによるCPU使用率が大幅に低下します。（バグ #31174015） ● DBSPJは、TRANSID_AI信号の保存と処理に、セグメント化されたメモリの代わりに線形メモリを使用するようになりました。これにより、以前は消費されていたCPUの約10％が節約されます。この変更により、DBSPJが短信号形式のTRANSID_AI信号を受け入れることができるようになりました。これは、セグメント化されたメモリを必要とする長い信号形式よりも効率的です。（バグ #31173582、バグ #31173766） ● ALGORITHM=INPLACEを使用して完全に複製されたテーブルのテーブルコメントを変更すると、アサーションが発生しました。（バグ #31139313） ● ローカルデータマネージャー（LDM）には、行が少なすぎて妥当な時間内に使用可能なバッチサイズを満たすことができない場合（スキャンされた行のほとんどでScanFilterがfalseと評価される場合など）にフラグメントスキャンが無期限に継続しないようにするメカニズムがあります。DBLQHで10ミリ秒として設定されているこの時間制限が経過すると、指定されたバッチサイズが満たされているかどうかに関係なく、その時点までに見つかった行が返されます。これは、データノードとAPIノードの間のキープアライブメカニズムとして機能するだけでなく、スキャン中にロックが長時間保持されないようにするために機能します。 これの副作用は、予想される制限を大幅に下回る結果行バッチをDBSPJブロックに返すと、パフォーマンスの問題が発生する可能性があることです。これは、バッチ用に予約されたスペースの使用率が低く、NEXTREQラウンドトリップがさらに必要になるためだけでなく、DBSPJの内部並列処理統計の信頼性が低下したためです。 DBSPJブロックはスキャンの実行時にロックを要求しないため、過度に長いロックはSPJリクエストの問題にはなりません。したがって、DBSPJによって要求されたスキャンを以前に許可された10ミリ秒より長く継続させることが安全であると見なされ、DBLQHで設定される制限は100ミリ秒に増やされました。（バグ #31124065） ● プッシュ結合の場合、EXPLAIN FORMAT=TREEからの出力は、テーブルアクセスが複数行を返すインデックス範囲スキャンであるか、プライマリキーまたは一意キーでの単一行ルックアップであるかを示しませんでした。 この修正は、アクセスタイプがUniqueであることがわかっている場合に複数の行を返そうとしてハンドラインターフェイスに複数回アクセスすることはないといった、マイナーな最適化も提供します。（バグ #31123930） ● 以前の変更（NDB 8.0.20で行われた）により、テーブルでのプッシュ結合が可能になり、READ_BACKUPがDBTCブロックのローカルデータノードに2つのSPJワーカーを配置できるようになり、他のノードにはSPJワーカーを配置できなくなりました。バックアップフラグメントのより多くのローカル読み取りを有効にすることによる利益と比較して、SPJワークロード（および発生する可能性のある不均衡）は通常非常に低いため、この時々の不均衡は意図的なものです。同じ変更の意図しない副作用として、これら2つの同じ場所に配置されたSPJワーカーは、フラグメントの同じサブセットを並行してスキャンする可能性があります。これは、各SPJワーカーが異なるフラグメントからスキャンを開始することを保証するロジックが依存する各データノードでインスタンス化されるSPJワーカーが1つだけであるという、DBSPJブロックの仮定を破りました。 この問題を修正するために、各SPJワーカーの開始フラグメントは、ワーカーの開始元のルートフラグメントIDに基づいて計算されるようになりました。これは、一部のSPJワーカーが同じノードに存在する場合でも、全てのSPJワーカーの間で一意です。（バグ #31113005） 参照：バグ #30639165。 ● クラスタをNDB 8.0.17以前から8.0.18以降にアップグレードする場合、1つの管理サーバー（または複数の管理サーバー）の新しいソフトウェアバージョンへのアップグレード後に、まだアップグレードされていないデータノードが予期せずシャットダウンする場合がありました。これは、管理クライアントのSTOPコマンドがまだ古いバージョンを実行している1つ以上のデータノードに送信され、（古いバージョンのNDBソフトウェアも実行している）新しいマスターノードがその後計画外のシャットダウンを受けた時に発生しました。 これは、GSN_STOP_REQ（より多くの数のデータノードをサポートするために行われた作業の一部としてNDB 8.0で長さが増加した多数の信号の1つ）を新しいマスターに送信する時に、信号の長さと信号セクションの数を正しく設定していないことが原因で発生したことがわかりました。これは、GSN_STOP_REQを前のマスターノードに送信して保持された古いデータを使用したために発生しました。この発生を回避するために、ndb_mgmdは、GSN_STOP_REQ信号を送信する前に、信号の長さとセクション数を毎回明示的に設定するようになりました。（バグ #31019990） ● ログの再生およびタプルの復元中にエラーが発生すると、ndb_restoreはエラーを返す代わりに終了する場合がありました。さらに、一部の操作で試行される再試行回数は、ハードコードされた値によって決定されました。（バグ #30928114） ● スキーマ配布中、DDL操作が既にndb_schemaテーブルに記録された後、参加者が応答する前に、クライアントが強制終了された場合、クライアントは単に全ての参加者をNDB_SCHEMA_OBJECTで失敗としてマークして返しました。配布プロトコルがすでに既に進行中であったため、コーディネーターは参加者を待ち続け、ndb_schema_result挿入を受け取り、それらを処理しました。その間、クライアントは別のDDL操作を送信するために開いていました。コーディネーターが前のスキーマ変更の処理を完了する前に1つが実行され、その配布が開始された場合、これにより、常にアクティブなスキーマ操作の配布は1つだけである必要があるというアサーションがトリガーされました。 さらに、クライアントがスレッドの強制終了を検出して戻ってきた時、クライアントはグローバルスキーマロック（GSL）も解放しました。参加者はGSLがまだコーディネーターによって保持されているという前提で変更を加えることができたため、これは未定義の問題につながる可能性もありました。 このような場合、クライアントは、DDL操作がndb_schemaテーブルに記録された後に戻るべきではありません。この時点から、コーディネーターが制御権を持ち、クライアントはコーディネーターが決定を下すのを待つ必要があります。現在、コーディネーターはサーバーまたはクラスタがシャットダウンした場合にのみ配布を中止し、それ以外の場合は全ての参加者が応答するか、タイムアウトしてスキーマ操作を完了としてマークするのを待ちます。（バグ #30684839） ● 再起動中に、データノードが開始フェーズ 9を開始する前にGCP_SAVEREQ信号を受信したため、ローカルデータマネージャーのローカルチェックポイント制御ファイルへのグローバルチェックポイントインデックスの書き込みを実行する必要がある場合、データノードは書き込まれたデータの一部として信号を送信したノードで発信されたDIHブロックからの情報を記録しませんでした。これは、開始フェーズ 9の後半で、GCP_SAVEREQに応答してGCP_SAVECONF信号を送信しようとした時に、この情報が利用できなかったことを意味します。つまり、応答は送信されず、データノードが計画外にシャットダウンされました。（バグ #30187949） ● EnableRedoControlをfalseに設定しても、MaxDiskWriteSpeed、MaxDiskWriteSpeedOtherNodeRestart、MaxDiskWriteSpeedOwnRestartが期待どおりに完全に無効になりませんでした。（バグ #29943227） 参照：バグ #31337487。 ● BLOB値は、NDBによって複数のパーツに格納されます。このような値を読み取る場合、1つの読み取り操作はパーツごとに実行されます。1つのパーツが見つからない場合、読み取りはrow not foundエラーで失敗します。これは、BLOBが欠落しているパーツを持たないため、BLOBが破損していることを示します。このエラーは読み取り操作の全体的な結果として報告されるため、問題が発生する可能性があります。つまり、mysqldはエラーを認識せず、ゼロ行が返されることを報告します。 この問題は、blobパーツが見つからない場合に特化したチェックを追加することで修正されています。現在、これが発生すると、corrupted blobでrow not foundエラーを上書きします。これにより、元のSELECTステートメントが期待どおりに失敗します。NDB APIのユーザーは、この変更にもかかわらず、NdbBlob::getValue()メソッドがそのような場合にrow not foundとしてエラーを報告し続けることに注意する必要があります。（バグ #28590428） ● RealtimeScheduler設定パラメータが1に設定されていると、データノードは開始しませんでした。これは、起動時のインデックス構築が一部のI/Oスレッドをインデックス構築スレッドとして使用するために一時的に迂回させることによって実行され、これらのスレッドがI/Oスレッドのリアルタイムプロパティを継承するということが原因でした。これは、インデックス構築スレッドの仕様がチェックされ、それらがリアルタイムスレッドではないことを確実にする時に、競合（致命的なエラーとして扱われる）を引き起こしました。これは、ホストI/Oスレッドに適用される設定に関係なく、インデックス構築スレッドがリアルタイムスレッドとして扱われないようにすることで修正されます。これは、実際に設計で意図されているとおりです。（バグ #27533538） ● インプレースのALTER TABLEを使用してインデックスを削除すると、SQLノードが計画外にシャットダウンする可能性がありました。（バグ #24444899） ● ALTER TABLE ... ALGORITHM=INPLACEを実行する時の最後のステップとして、NDBCLUSTERはNDBディクショナリからテーブルメタデータの読み取りを実行し、SQLノードとデータノードの間の余分なラウンドトリップを必要としました。これにより、不必要に、ステートメントの実行が遅くなり、NDBCLUSTERが正しく処理する準備ができていなかったエラーの手段が提供されました。この問題は、インプレースのALTER TABLEステートメントの実行の最終段階でのNDBテーブルメタデータの読み取りを削除することで修正されています。（バグ #99898、バグ #31497026） ● インプレースのALTER TABLE用にNDBテーブルを準備する時に、メモリリークが発生する可能性がありました。（バグ #99739、バグ #31419144） ● AllowUnresolvedHostNames設定パラメータが追加されました。trueに設定すると、このパラメータは、ndb_mgmdが特定のホスト名に接続できない場合に通常発生する致命的なエラーをオーバーライドし、代わりに起動を続行して警告のみを生成できるようにします。有効にするためには、このパラメータをクラスタグローバル設定ファイルの[tcp default]セクションで設定する必要があります。
MySQL NDB Cluster 8.0.22リリースノート（MySQLウェブサイト）： https://dev.mysql.com/doc/relnotes/mysql-cluster/8.0/en/news-8-0-22.html
MySQL Editions
MySQLのサブスクリプションは、24時間365日体制でお客様をサポートいたします。さらに MySQL Enterprise Edition では、データベース管理者支援ツール MySQL Enterprise Monitor やバックアップツール MySQL Enterprise Backup をご利用いただけます。