MySQL NDB Cluster 8.0.31 GA版（リリース日：2022年9月15日）

透過的データ暗号化 (TDE)

このリリースでは、透過的データ暗号化（TDE）が実装されており、保管中のNDBデータの暗号化による保護が提供されます。これには、ディスクに永続化される全てのNDBテーブルデータとログファイルが含まれ、テーブルスペースファイルやログなどのMySQL Clusterデータファイルへの無許可アクセスに続くデータの回復から保護することを目的としています。
NDBテーブルデータを格納するファイルに暗号化を適用するためには、EncryptedFileSystemを1に設定します。これにより、これらのファイルへの書き込みと読み取りが行われる時に、全てのデータが必要に応じて暗号化および復号化されます。これらには、LCPデータファイル、REDOログファイル、テーブルスペースファイル、UNDOログファイルが含まれます。
NDBでファイルシステム暗号化を使用する場合は、次のタスクも実行する必要があります：

• • データノードオプション --filesystem-passwordまたは--filesystem-password-from-stdinのいずれかを使用してデータノードを起動または再起動する時に、各データノードにパスワードを指定します。このパスワードは、暗号化されたNDBバックアップに使用されるパスワードと同じ形式を使用し、同じ制約を受けます。
    コマンドラインまたはmy.cnfファイルで暗号化パスワードを指定できます。

NDBストレージエンジンを使用するテーブルだけが、この機能による暗号化の対象となります。NDBスキーマの配布、レプリケーション、およびバイナリロギングに使用されるテーブルなどの他のテーブルは、通常、InnoDBを使用します。オペレーティングシステムログ、クラッシュログ、コアダンプなどのNDBプロセスによって生成または使用されるファイルは暗号化されません。NDB によって使用されるがユーザーテーブルデータを含まないファイルも暗号化されません。これらには、LCP制御ファイル、スキーマファイル、およびシステムファイルが含まれます。管理サーバー設定キャッシュも暗号化されません。
さらに、NDB 8.0.31は、暗号化されたファイルからキー情報を抽出するための新しいユーティリティ ndb_secretsfile_readerを追加します。
この拡張機能は、暗号化されたNDBバックアップを実装するためにNDB 8.0.22で行われた作業に基づいています。

注意：
暗号化されたファイルシステムを以前のリリースからNDB 8.0.31以降にアップグレードするためには、キー処理の改善により、データノードのローリング初期再起動が必要です。

(バグ #34417282)

RPM関連

• ndbinfo情報データベース: RPMファイルを使用してSQLノードをNDB 7.5またはNDB 7.6からNDB 8.0にアップグレードすると、ndbinfoプラグインが適切に有効になりませんでした。これは、mysqldのアップグレード中にndbclusterプラグインが無効になるため、ndbinfoプラグインも無効になるためです。これにより、ndbinfoテーブルに関連付けられた.frmファイルがアップグレード後に取り残されました。
  このような場合、以前のリリースのndbinfoテーブル .frmファイルは全て削除され、プラグインが有効になります。 (バグ #34432446)

追加・変更された機能

• 重要な変更: NDBクライアントプログラム: 多くのNDBプログラムオプションが実装されず、削除されました。オプションとそれらが削除されたプログラムは次のとおりです。
  • --ndb-optimized-node-selection: ndbd, ndbmtd, ndb_mgm, ndb_delete_all, ndb_desc, ndb_drop_index, ndb_drop_table, ndb_show_tables, ndb_blob_tool, ndb_config, ndb_index_stat, ndb_move_data, ndbinfo_select_all, ndb_select_count
  • --character-sets-dir: ndb_mgm, ndb_mgmd, ndb_config, ndb_delete_all, ndb_desc, ndb_drop_index, ndb_drop_table, ndb_show_tables, ndb_blob_tool, ndb_config, ndb_index_stat, ndb_move_data, ndbinfo_select_all, ndb_select_count, ndb_waiter
  • --core-file: ndb_mgm, ndb_mgmd, ndb_config, ndb_delete_all, ndb_desc, ndb_drop_index, ndb_drop_table, ndb_show_tables, ndb_blob_tool, ndb_config, ndb_index_stat, ndb_move_data, ndbinfo_select_all, ndb_select_count, ndb_waiter
  • --connect-retries: ndb_mgmd, ndb_waiter
  • --connect-retry-delay: ndb_mgmd, ndb_waiter
  • --ndb-nodeid: ndb_config

  (バグ #34059253)

• 重要な変更: ndbclusterプラグインは、32ビットプラットフォーム用のビルドを除いて、全てのMySQLサーバービルドに含まれるようになりました。この作業の一環として、NDB Clusterのcmakeオプションに関する多くの問題に対処し、NDBCLUSTERのプラグインオプションを他のプラグインオプションとして動作させ、新しいオプション WITH_NDBを追加して MySQL ClusterのNDBのビルドを制御します。
  このリリースでは、MySQL Clusterに関連するcmakeオプションに次の変更が加えられています。
  • WITH_NDBオプションを追加します（デフォルトはOFF）。このオプションを有効にすると、MySQL Clusterバイナリがビルドされます。
  • WITH_NDBCLUSTERオプションは非推奨です。代わりにWITH_NDBを使用してください。
  • WITH_PLUGIN_NDBCLUSTERオプションを削除します。MySQL Clusterを構築するためには、代わりにWITH_NDBを使用してください。
  • WITH_NDBCLUSTER_STORAGE_ENGINEオプションを変更して、ndbclusterプラグイン自体をビルドするかどうか（のみ）をコントロールするようにします。ビルドでWITH_NDBが有効になっている場合、このオプションは自動的にONに設定されるようになりました。そのため、MySQLをNBD Clusterサポートでコンパイルする時に設定する必要がなくなりました。
• ndbxfrmに--detailed-infoオプションを追加しました。これは、--infoオプションに似ていますが、さらにファイルのヘッダーとトレーラーを出力します。 (バグ #34380739)
• このリリースでは、MySQLサーバーの実行中に、mysqlまたはその他のクライアントセッションでNDBテーブルのZSTD圧縮を使用して、圧縮されたトランザクションでバイナリロギングを有効または無効にすることができます。この機能を有効にするためには、このリリースで導入されたndb_log_transaction_compressionシステム変数をONに設定します。使用される圧縮のレベルは、このリリースで追加されたndb_log_transaction_compression_level_zstdシステム変数を使用して制御できます。デフォルトの圧縮レベルは3です。注意：
  クライアントセッションからbinlog_transaction_compressionおよびbinlog_transaction_compression_level_zstdシステム変数の値を変更しても、NDBテーブルのバイナリログには影響しませんが、コマンドラインまたはmy.cnfファイルで--binlog-transaction-compression=ONを設定すると、ndb_log_transaction_compressionが--ndb-log-transaction-compressionの設定に関係なく、有効になります。この場合、NDBテーブル（のみ）のバイナリログトランザクション圧縮を無効にするためには、mysqldの起動後にMySQLクライアントセッションでndb_log_transaction_compression=OFFを設定します。

  (バグ #32927582)

主なバグ修正

• プッシュされた結合の一部として条件をプッシュする場合、全てのtable.column参照が次のいずれかにある必要があります。
  • 条件自体がプッシュされるテーブル
  • プッシュされた結合のルートの祖先であるテーブル
  • プッシュされたクエリツリー内のテーブルの祖先であるテーブル

  最後のケースでは、可能性のある祖先を見つける時に、次の2つの方法のいずれかまたは両方で、そのようなテーブルの全ての候補を完全には特定できませんでした。
  a. ネストレベルの依存関係のために祖先が必要なテーブルは、祖先として追加されませんでした
  b. 必要とされる祖先またはキーの親として全ての可能な祖先を持つテーブルは、祖先と直接結合され、これらを祖先自体として提供することが知られています。したがって、そのようなテーブルも祖先として使用できるようにする必要があります。
  このパッチは、ケース1と2の両方を実装します。2番目のケースでは、保守的なアプローチを採用し、単一行ルックアップアクセスタイプを持つテーブルのみを追加し、インデックススキャンを使用するテーブルは追加しません。 (バグ #34508948)

• ndb_join_pushdownが有効（デフォルト）の一部の大規模な結合クエリに対するEXPLAINの実行は、NDBエラー QRY_NEST_NOT_SUPPORTED FirstInner/Upper has to be an ancestor or a siblingで拒否されました。 (バグ #34486874)
• NDBジョインプッシュダウンハンドラは、プッシュダウンできないテーブルを見つけると、関連するテーブルの名前を含む、拒否の理由を伝える説明メッセージを生成しようとします。一部のケースでは、オプティマイザが既にテーブルを最適化していたため、NDBハンドラがテーブルにアクセスできなくなり、クエリが失敗していました。
  このような場合のチェックを導入し、テーブルが見つからない場合はテーブル名を含まないより一般的なメッセージを出力することで、これを修正します。 (バグ #34482783)
• EncryptedFilesystemパラメータは、CI_RESTART_INITIALで定義されていなかったため、ndb_configの出力に --initialが必要であると表示されませんでした。ただし、実際にはパラメータを有効にするためには最初の再起動が必要です。 (バグ #34456384)
• プッシュ結合でプッシュダウンできるテーブルを見つける時、テーブルのプッシュ可能性は、後のテーブルも同様にプッシュされるかどうかによって異なります。このような場合、私たちは楽観的なアプローチを取り、後のテーブルもプッシュされると想定します。この仮定が失敗した場合は、テーブルとそれに依存する他のテーブルを"プッシュ解除"する必要があるかもしれません。このような連鎖的な"プッシュ解除"は、次の条件のいずれかまたは両方が原因である可能性があります。
  • キー参照が、後でプッシュできないことが判明したテーブルの列を参照していました。
  • プッシュされた条件が、後でプッシュできないことが判明したテーブルの列を参照していました。

  前に最初のケースを処理しましたが、同じプッシュされた結合の一部である他のテーブルからの列を参照する条件をプッシュできるようにするために、NDB 8.0.27で行われた作業から 2番目のケースの処理が省略されました。 (バグ #34379950)

• NdbScanOperationエラーは、おそらくクライアントが他の処理を行っている間に、クライアントに非同期で返されます。NdbTransaction::execute()への呼び出しの成功は、スキャンリクエストがアセンブルされ、エラーなしでトランザクションコーディネーターに送信されたことのみを保証します。データノードから返されるCONFまたはREF信号を待機しません。この特定のケースでは、予期されたTAB_SCANREFシグナルが、おそらくクライアントがまだ他の操作を実行している間に、非同期的にクライアント空間に返されました。
  TAB_SCANREFエラーが受信された時にNdbTransactionエラーコードを設定しないことで、この動作をより確定的にします。 (バグ #34348706)
• NDBテーブルのプライマリキーの一部であるVARCHARカラムを更新しようとすると、cmp_attr()メソッドに提供されたデータベースから読み込まれた値の長さが正しくなかったと報告されていました。この問題の修正に加えて、このメソッドへの引数のバイナリバイト長が同じであることを必要とする不適切な長さチェックも削除しました。これは、比較セマンティクスが文字セットと照合によって定義される文字として比較される属性には当てはまりません。 (バグ #34312769)
• デバッグビルドに-Ogを使用してOEL7およびOEL8でNDB Clusterをコンパイルすると、gccでヌルポインタ減算エラーが発生しました。 (バグ #34199675、バグ #34199732)
  参照: バグ #33855533。
• ndb_blob_toolは、データの読み取り中に発生したエラーを適切に処理しませんでした。 (バグ #34194708)
• シグナル実行戦略の設定の一環として、各ジョブバッファから実行するシグナルの最大数の安全なクォータを計算します。実行された各シグナルは、最大4つの外向きシグナルを生成すると想定されるため、アウトバッファをオーバーフィルしないように、シグナルクォータを制限する必要がある場合があります。事実上、シグナル実行の各ラウンドでは、出力バッファに収まるシグナルの1/4を超えるシグナルを実行することはできません。
  この計算では、NDB 8.0.23で行われた作業が考慮されていないため、複数のライターが存在する可能性があり、全て同じジョブバッファ内の同じ利用可能な空き領域を使用します。そのため、同じバッファに書き込むワーカー間でシグナルクォータをさらに分割する必要がありました。
  現在は、実行するシグナルの最大数の計算では、結果として各キューへのライターの数が増える可能性が考慮されます。 (バグ #34065930)
• NDBスケジューラがジョブバッファがいっぱいであることを検出し、予約されたバッファから割り当てを開始すると、コンシューマを待機している間にCPUを解放することが期待されます。解放する直前に、スリープする前に、この状態の最終チェックを実行します。このチェックでジョブバッファがいっぱいではないことが示されたために、実行が許可されているシグナルの数の制限がまだ0であるにもかかわらず、スケジューラがシグナルの実行を続行できることが示された時に問題が発生しました。これにより、何のシグナルも実行せず、続いて別のyieldチェックなどが行われ、受信側スレッドによって何かが消費されるのを待つ間、理由もなくCPUが占有されたままになります。
  この問題の根本的な原因は、実行するシグナルの制限を計算するため（この制限が0の場合にyieldチェックをトリガーする）と、その後ジョブバッファが実際にいっぱいかどうかをチェックするyieldコールバックに、異なるメトリックが使用されていたことです。
  MySQL NDB Cluster 8.0.23でスケーラブルなジョブバッファが実装される前は、NDBは追加のジョブバッファを最大10回待機していました。これは誤って変更されたため、NDBが10回スリープしたことを示すログメッセージが表示されていたにもかかわらず、1回だけ待機した後に停止しました。この修正の一環として、その変更を元に戻し、以前と同様に、諦める前に最大10回まで追加のジョブバッファを待ちます。この作業の追加部分として、スピン待機を検出するために以前に追加された余分な（および不要な）コードも削除します。 (バグ #34038016)
  参照: バグ #33869715、バグ #34025532。
• ジョブバッファは、データノードの内部ブロックスレッド間の通信リンクとして機能します。これらのデータ構造が初期化されると、これらのスレッドが（設計上）互いに通信しない場合でも、32Kページがそのようなリンクそれぞれに割り当てられます。これはメモリリソースを浪費し、使用可能なシグナルについてジョブバッファページが頻繁にチェックされるため、パフォーマンスにわずかな影響がありました。そのため、未使用のジョブバッファページをトランスレーションルックアサイドバッファと L1、L2、およびL3キャッシュにロードする必要がありました。
  現在は、代わりに、全ての通信リンクが最初に参照するセンチネルとして、空のジョブバッファを設定します。実際の（使用された）ジョブバッファページは、ページがいっぱいになった時に新しいメモリページが割り当てられるのと同じ方法で、実際に信号を書き込む時にのみ割り当てられるようになりました。 (バグ #34032102)
• ローカルバッファがまだ使用可能な場合でも、ジョブバッファがいっぱいになると、データノードが強制的にシャットダウンされる可能性がありました。 (バグ #34028364)
• ジョブスケジューラによる保留中のシグナルのチェックの一貫性と信頼性が向上しました。 (バグ #34025532)
  参照: バグ #33869715、バグ #34038016。
• キーごとの複数の処理中の操作を伴うバッチ処理、IgnoreErrorの使用、非プライマリレプリカで発生する一時的なエラーの組み合わせにより、場合によってはDBTUP内で不整合が発生し、レプリカの不整合やその他の問題が発生しました。非プライマリレプリカで操作が失敗した時を検出し、そのような場合に含まれているトランザクションに対して AbortOnError処理（ロールバック）を強制することで、これが発生するのを防ぎます。 (バグ #34013385)
• DDL操作によって発生した一時エラーのndb_restoreによる処理が改善され、一貫性が保たれました。そのような全ての場合において、ndb_restoreは、あきらめる前にMAX_RETRIES (11)回まで操作を再試行するようになりました。 (バグ #33982499)
• NDB Clusterのコンパイル時に発生する多くの警告の原因を取り除きました。 (バグ #33797357、バグ #33881953)
• 変更率が高い場合、イベントサブスクライバーが受信を確認するのが遅い場合、または、その両方の場合、SUMAブロックがイベントをバッファするためのスペースを使い果たす可能性がありました。 (バグ #30467140)
• ALTER TABLE ... COMMENT="NDB_TABLE=READ_BACKUP=1" または ALTER TABLE..COMMENT="NDB_TABLE=READ_BACKUP=0"は、テーブルに対して非コピー（オンライン）ALTER操作を実行して、そのREAD_BACKUPプロパティを追加または削除します。これは、テーブルの全てのインデックスのインデックスバージョンをインクリメントします。以前のインデックスバージョンを使用して保存された既存の統計は孤立し、削除されることはありませんでした。これにより、インデックス統計を収集する際にメモリが浪費され、検索が非効率的になりました。
  インデックスサンプルをクリーンアップすることで、これらの問題に対処します。サンプルバージョンが現在のサンプルバージョンより大きいまたは小さいサンプルは全て削除されます。さらに、既存の統計がインデックスのIDとバージョンによって見つからない場合、およびインデックスが削除された場合。この最後のケースでは、削除操作の境界を緩和し、インデックスのIDとインデックスのバージョンの両方ではなく、問題のインデックス IDに対応する全てのエントリを削除します。
  この修正により、大量のインデックス統計データを格納するサンプルテーブルがクリーンアップされます。実際の統計ではなくインデックスメタデータで構成されるヘッドテーブルには、孤立した行がまだ含まれていますが、これらはわずかな量のメモリを占有するため、統計の検索効率に悪影響を与えることはなく、古いエントリはインデックスのIDとバージョンが再利用される時にクリーンアップされます。
  (バグ #29611297)

---

全ての変更点やバグ修正については、以下のページをご覧ください。
MySQL NDB Cluster 8.0.31リリースノート（MySQLウェブサイト）：

https://dev.mysql.com/doc/relnotes/mysql-cluster/8.0/en/news-8-0-31.html

---

MySQL Editions

MySQLのサブスクリプションは、24時間365日体制でお客様をサポートいたします。さらに MySQL Enterprise Edition では、データベース管理者支援ツール MySQL Enterprise Monitor やバックアップツール MySQL Enterprise Backup をご利用いただけます。