互換性の強化.  次の変更により、他の MySQL ストレージエンジンと比較して、NDB の動作における重要でない長期的な違いが軽減されます:

スキーマとメタデータの分散および同期.  NDB 8.0 では、MySQL データディクショナリを使用して、クラスタに参加している SQL ノードにスキーマ情報を分散し、既存の SQL ノード間で新しいスキーマ変更を同期します。 次のリストでは、この統合作業に関連する個々の拡張機能について説明します:

NDB_STORED_USER とのユーザー権限の同期.  NDB 8.0.18 以降では、NDB_STORED_USER 権限を使用して、SQL ノード間でユーザー、役割、および特権を共有および同期するための新しいメカニズムを使用できます。 NDB 7.6 以前で実装された分散特権 (Distributed Privileges Using Shared Grant Tables を参照) はサポートされなくなりました。

SQL ノードでユーザーアカウントが作成されると、ユーザーとその権限を NDB に格納できるため、次のような GRANT ステートメントを発行して、クラスタ内のすべての SQL ノード間で共有できます:

GRANT NDB_STORED_USER ON *.* TO 'jon'@'localhost';

NDB_STORED_USER は常にグローバルスコープを持ち、ON *.* を使用して付与する必要があります。 mysql.session@localhost や mysql.infoschema@localhost などのシステム予約アカウントには、この権限を割り当てることはできません。

適切な GRANT NDB_STORED_USER ステートメントを発行して、ロールを SQL ノード間で共有することもできます。 このようなロールをユーザーに割り当てても、ユーザーは共有されません。NDB_STORED_USER 権限は、各ユーザーに明示的に付与する必要があります。

NDB_STORED_USER を持つユーザーまたは役割は、その特権とともに、特定の NDB Cluster に参加するとすぐにすべての SQL ノードと共有されます。 ユーザーまたはロールの権限に対する変更は、接続されているすべての SQL ノードとただちに同期されます。 このような変更は接続されている任意の SQL ノードから行うことができますが、異なる SQL ノードからの権限に影響するステートメントの実行順序はすべての SQL ノードで同じであることが保証されないため、指定された SQL ノードからのみ行うことをお薦めします。

アップグレードの意味.  MySQL サーバー特権システム (セクション6.2.3「付与テーブル」 を参照) が変更されたため、NDB ストレージエンジンを使用する特権テーブルは NDB 8.0 で正しく機能しません。 NDB 7.6 以前で作成されたこのような特権テーブルを保持する必要はありませんが、アクセス制御には使用されなくなりました。 NDB 8.0.16 以降、SQL ノードとして機能し、NDB でこのようなテーブルを検出する mysqld は、MySQL サーバーログに警告を書き込み、InnoDB シャドウテーブルをそれ自体に対してローカルに作成します。このようなシャドウテーブルは、クラスタに接続されている各 MySQL サーバー上に作成されます。 NDB 7.6 以前からアップグレードを実行する場合、SQL ノードとして機能するすべての MySQL サーバーがアップグレードされると、NDB を使用している特権テーブルを ndb_drop_table を使用して安全に削除できます (セクション23.2.7「NDB Cluster のアップグレードおよびダウングレード」 を参照)。

ndb_restore ユーティリティーの --restore-privilege-tables オプションは非推奨ですが、NDB 8.0 では引き続き適用され、以前のリリースの NDB Cluster から取得されたバックアップに存在する分散特権テーブルを NDB 8.0 を実行しているクラスタに復元するために引き続き使用できます。 これらのテーブルは、前の段落で説明されているように処理されます。

共有ユーザーおよび権限は ndb_sql_metadata テーブルに格納されますが、NDB 8.0.19 以降の ndb_restore ではデフォルトで復元されません。--include-stored-grants オプションを指定してこれを行うことができます。

INFORMATION_SCHEMA の変更点.  INFORMATION_SCHEMA.FILES テーブルのディスクデータファイルに関する情報の表示では、次の変更が行われます:

また、INFORMATION_SCHEMA テーブルには、MySQL クラスタテーブルのテーブルスペース統計が移入されるようになりました。 (Bug #27167728)

ndb_perror のエラー情報.  perror の非推奨の --ndb オプションは削除されました。 かわりに、ndb_perror を使用して、NDB エラーコードからエラーメッセージ情報を取得します。 (Bug #81704、Bug #81705、Bug #23523926、Bug #23523957)

条件プッシュダウンの拡張機能.  以前は、条件プッシュダウンは、条件がプッシュされたのと同じテーブルのカラム値を参照する述語条件に制限されていました。 NDB 8.0.16 では、この制限は、クエリープラン内の以前のテーブルのカラム値をプッシュされた条件から参照することもできるように削除されます。 NDB 8.0.18 では、同じテーブル内のカラム間の比較と同様に、カラム式を比較する結合がサポートされています。 比較するカラムおよびカラム式は、完全に同じタイプである必要があります。つまり、これらの属性が適用される場合は常に、同じ符号性、長さ、文字セット、精度およびスケールである必要があります。

条件の大きな部分をプッシュダウンすると、データノードによってより多くの行をフィルタで除外できるため、結合処理中に mysqld が処理する必要がある行数が削減されます。 これらの拡張機能の別の利点は、SQL ノード上の単一の mysqld プロセスではなく、LDM スレッドで並列でフィルタリングを実行できることです。これにより、クエリーのパフォーマンスが大幅に向上する可能性があります。

比較対象のカラム値間の型の互換性に関する既存のルールが引き続き適用されます (セクション8.2.1.5「エンジンコンディションプッシュダウンの最適化」 を参照)。

NDB 8.0.21 では、次の追加の改善が行われています:

最大行サイズの増加.  NDB 8.0.18 は、NDBCLUSTER テーブルに格納できる最大バイト数を 14000 から 30000 バイトに増やします。

BLOB または TEXT カラムは、以前と同様に、この合計の 264 バイトを引き続き使用します。

NDB テーブルの固定幅カラムの最大オフセットは 8188 バイトです。これは、8.0.18 より前のリリースからも変更されていません。

詳細は、セクション23.1.7.5「NDB Cluster 内のデータベースオブジェクトに関連付けられる制限」を参照してください。

ndb_mgm SHOW コマンドおよびシングルユーザーモード.  NDB 8.0.17 以降では、シングルユーザーモードのクラスタの場合、管理クライアントの SHOW コマンドの出力に、このモードが有効なときに排他的アクセス権を持つ API または SQL ノードが示されます。

オンラインカラム名の変更.  NDB 8.0.18 以降では、ALGORITHM=INPLACE を使用して NDB テーブルのカラムの名前をオンラインで変更できます。 詳しくはセクション23.5.11「NDB Cluster での ALTER TABLE を使用したオンライン操作」,をご覧ください。

ndb_mgmd の起動時間の改善.  NDB 8.0.18 以降では、管理ノードデーモンの起動時間が次のように大幅に改善されました:

NDB API の拡張機能.  NDB 8.0.18 以降では、NdbScanFilter::cmp() と NdbInterpretedCode のいくつかの比較方法を使用して、テーブルカラム値を相互に比較できます。 影響を受ける NdbInterpretedCode メソッドを次に示します:

前述のすべての方法で、比較されるテーブルのカラム値は、長さ、精度、符号性、スケール、文字セットおよび照合順序に関して、正確に一致する型である必要があります。

詳細は、個々の API メソッドの説明を参照してください。

オフラインマルチスレッドインデックスの構築.  ファイル I/O、圧縮、解凍などの通常の I/O 職務とは対照的に、順序付けられたインデックスのオフラインマルチスレッドビルドを実行する I/O スレッドに使用するコアのセットを指定できるようになりました。 このコンテキストの「「オフライン」」とは、親テーブルが書き込まれていないときに実行される順序付けされたインデックスの構築を指します。このような構築は、NDB クラスタがノードまたはシステムの再起動を実行したとき、または ndb_restore --rebuild-indexes を使用したバックアップからのクラスタのリストアの一環として行われます。

また、オフラインインデックス作成作業のデフォルトの動作は、I/O スレッド用に予約されたコアに制限されるのではなく、ndbmtd で使用可能なすべてのコアを使用するように変更されます。 これにより、再起動とリストアの時間、パフォーマンス、可用性およびユーザーエクスペリエンスを向上させることができます。

この拡張機能は、次のように実装されます:

また、NDB では、次の 2 つの基準によって ThreadConfig にアクセス可能なスレッドタイプが区別されるようになりました:

追加情報については、マニュアルで示されているパラメータの説明を参照してください。 (Bug #25835748、Bug #26928111)

logbuffers テーブルバックアッププロセス情報.  NDB バックアップを実行すると、ndbinfo.logbuffers テーブルに、各データノード上のバックアッププロセスによるバッファーの使用状況に関する情報が表示されるようになりました。 これは、REDO および DD-UNDO に加えて、2 つの新しいログタイプを反映する行として実装されます。 これらのいずれかの行のログタイプは BACKUP-DATA で、バックアップ中にフラグメントをバックアップファイルにコピーするために使用されるデータバッファの量が表示されます。 もう一方の行のログタイプは BACKUP-LOG で、バックアップの開始後に行われた変更を記録するためにバックアップ中に使用されたログバッファの量が表示されます。 これらの log_type 行のそれぞれが、クラスタ内の各データノードの logbuffers テーブルに表示されます。 これら 2 つのログタイプを持つ行は、NDB バックアップが現在進行中の場合にのみテーブルに存在します。 (Bug #25822988)

Windows 上の ndbinfo.processes テーブル.  mysqld を生成および再起動するために RESTART によって Windows プラットフォームで使用されるモニタープロセスのプロセス ID が、angel_pid として processes テーブルに表示されるようになりました。

文字列ハッシュの改善.  NDB 8.0 より前では、すべての文字列ハッシュは、最初に文字列を正規化された形式に変換してから、結果のバイナリイメージを MD5 ハッシュ化することに基づいていました。 これにより、次の理由でパフォーマンスの問題が発生する可能性があります:

照合には独自のハッシュ関数が用意されており、最初に正規化された文字列を作成せずに文字列を直接ハッシュします。 また、Unicode 9.0 照合の場合、ハッシュはパディングなしで計算されます。 Unicode 9.0 照合順序を使用して識別された文字列をハッシュするたびに、NDB でこの組込み関数が利用されるようになりました。

他の照合の場合、変換された文字列でハッシュパーティション化されている既存のデータベースが存在するため、NDB では、これらを使用する文字列をハッシュ化するための以前の方法を引き続き使用して互換性を維持します。 (Bug #89590、Bug #89604、Bug #89609、Bug #27515000、Bug #27523758、Bug #27522732)

RESET MASTER の変更.  MySQL Server はグローバル読み取りロックを使用して RESET MASTER を実行するようになったため、NDB Cluster で使用された場合のこのステートメントの動作は、次の 2 つの点で変更されました:

ndb_restore オプションの使用方法.  NDB 8.0.16 以降では、ndb_restore を呼び出すときに --nodeid と --backupid の両方のオプションが必要です。

ndb_log_bin のデフォルト.  NDB 8.0.16 以降、ndb_log_bin システム変数のデフォルト値が TRUE から FALSE に変更されました。

動的トランザクションリソース割当て.  トランザクションコルディネータ (The DBTC Block を参照) でのリソースの割当ては、動的メモリープールを使用して実行されるようになりました。 これは、MaxDMLOperationsPerTransaction, MaxNoOfConcurrentIndexOperations, MaxNoOfConcurrentOperations, MaxNoOfConcurrentScans, MaxNoOfConcurrentTransactions, MaxNoOfFiredTriggers, MaxNoOfLocalScans などのデータノード構成パラメータによって決定されるリソース割り当てと TransactionBufferMemory が、これらの各パラメータによって表される負荷がそのようなすべてのリソースのターゲット負荷内にある場合、使用可能なリソースの合計を超えないように制限できることを意味します。

この作業の一環として、次に示すように、DBTC のトランザクションリソースを制御するいくつかの新しいデータノードパラメータが追加されました:

詳細は、前述のパラメータの説明を参照してください。

データノードごとに複数の LDM を使用したバックアップ.  複数のローカルデータマネージャ (LDM) を使用して、個々のデータノードで NDB バックアップをパラレルに実行できるようになりました。 (以前は、バックアップはデータノード間で並列で実行されていましたが、常にデータノードプロセス内でシリアル化されていました。) ndb_mgm クライアントの START BACKUP コマンドでこの機能を有効にするために特別な構文は必要ありませんが、すべてのデータノードが複数の LDM を使用している必要があります。 つまり、データノードは ndbmtd を実行している必要があり (ndbd はシングルスレッドであるため、常に LDM が 1 つしかありません)、バックアップを取得する前に複数の LDM を使用するように構成する必要があります。これを行うには、マルチスレッドデータノード構成パラメータ MaxNoOfExecutionThreads または ThreadConfig のいずれかに適切な設定を選択します。

複数の LDM を使用したバックアップでは、サブディレクトリが LDM ごとに BACKUP/BACKUP-backup_id/ディレクトリの下に作成されます。ndb_restore では、これらのサブディレクトリが自動的に検出されるようになり、存在する場合は、バックアップのパラレルリストアが試行されます。詳細は、セクション23.4.23.3「パラレルで作成されたバックアップからのリストア」 を参照してください。 (シングルスレッドバックアップは、以前のバージョンの NDB と同様にリストアされます。) 通常の復元手順を変更することによって、以前のバージョンの NDB Cluster から ndb_restore バイナリを使用して並列で作成されたバックアップを復元することもできます。これを行う方法については、セクション23.4.23.3.2「パラレルバックアップのシリアルリストア」 を参照してください。

バイナリ構成ファイルの拡張.  NDB 8.0.18 以降では、管理サーバーのバイナリ構成ファイルに新しい形式が使用されます。 以前は、クラスタ構成ファイルに最大 16381 個のセクションが表示されていましたが、セクションの最大数は 4G でした。 これは、この変更前に可能だったよりも多くのノードをクラスタでサポートすることを目的としています。

新しい形式へのアップグレードは比較的シームレスであり、管理サーバーは問題なく古い形式を読み取ることができるため、手動操作が必要になることはほとんどありません。 NDB 8.0.18 (またはそれ以降) から古いバージョンの NDB Cluster ソフトウェアへのダウングレードでは、バイナリ構成ファイルを手動で削除するか、--initial オプションを使用して古い管理サーバーバイナリを起動する必要があります。

詳細は、セクション23.2.7「NDB Cluster のアップグレードおよびダウングレード」を参照してください。

データノードの数の増加.  NDB 8.0.18 は、クラスタごとにサポートされるデータノードの最大数を 144 に増やします (以前は 48 でした)。 データノードは、1 から 144 の範囲のノード ID を使用できるようになりました。

以前は、管理ノードの推奨ノード ID は 49 および 50 でした。 これらは引き続き管理ノードでサポートされますが、これを使用するとデータノードの最大数が 142 に制限されるため、ノード ID 145 および 146 を管理ノードに使用することをお勧めします。

この作業の一環として、データノード sysfile に使用される形式がバージョン 2 に更新されました。 このファイルには、各ノードの最後のグローバルチェックポイントインデックス、再起動ステータス、ノードグループメンバーシップなどの情報が記録されます (NDB Cluster Data Node File System Directory を参照)。

RedoOverCommitCounter および RedoOverCommitLimit の変更.  これらを 0 に設定するセマンティクスがあいまいなため、NDB 8.0.19 以降、データノード構成パラメータ RedoOverCommitCounter および RedoOverCommitLimit のそれぞれの最小値が 1 に増加しました。

ndb_autoincrement_prefetch_sz の変更点.  NDB 8.0.19 では、ndb_autoincrement_prefetch_sz サーバーシステム変数のデフォルト値が 512 に増加しています。

パラメータ maxmimums および default の変更.  NDB 8.0.19 は、構成パラメータの最大値とデフォルト値を次のように変更します:

ディスクデータチェックポイントの改善.  NDB Cluster 8.0.19 には、ソリッドステートドライブなどの不揮発性メモリーデバイスおよびそのようなデバイスの NVMe 仕様を使用する場合に、「ディスクデータ」テーブルおよびテーブルスペースのチェックポイントの待機時間を短縮するのに役立つ多くの新しい拡張機能が用意されています。 これらの改善点には、次のリストの改善点が含まれます:

この作業の一環として、NDB 8.0.19 には 2 つの新しいデータノード構成パラメータが導入されています。 MaxDiskDataLatency では、ディスクアクセスに許可されるレイテンシの程度に上限が設定され、この時間よりもトランザクションの中断に時間がかかります。 DiskDataUsingSameDisk では、このようなテーブルスペースのチェックポイントを実行できる速度を上げることで、別々のディスク上の「ディスクデータ」テーブルスペースを利用できます。

さらに、ここに一覧表示されている ndbinfo データベース内の 3 つの新しいテーブルは、ディスクデータパフォーマンスに関する情報を提供します (こちらも NDB 8.0.19 で追加):

メモリー割当てと TransactionMemory.  NDB 8.0.19 では、トランザクションおよびローカルデータマネージャー (LDM) メモリーをプールするために実行される作業の一環として、トランザクションのデータノードメモリーの割り当てを簡略化する新しい TransactionMemory パラメータが導入されました。 このパラメータは、非推奨になったいくつかの古いトランザクションメモリーパラメータを置き換えることを目的としています。

トランザクションメモリーは、次の 3 つの方法のいずれかで設定できるようになりました:

詳細は、TransactionMemory および セクション23.3.3.13「データノードのメモリー管理」 の説明を参照してください。

追加のフラグメントレプリカのサポート.  NDB 8.0.19 は、本番でサポートされるフラグメントレプリカの最大数を 2 から 4 に増やします。 (以前は、NoOfReplicas を 3 または 4 に設定できましたが、テストで正式にサポートまたは検証されていませんでした。)

スライスによる復元.  NDB 8.0.20 以降では、ndb_restore に実装されている 2 つの新しいオプションを使用して、バックアップをほぼ同じ部分 (スライス) に分割し、これらのスライスを並列で復元できます:

これにより、ndb_restore の複数のインスタンスを使用してバックアップのサブセットをパラレルにリストアできるため、リストア操作の実行に必要な時間が短縮される可能性があります。

詳細は、ndb_restore --num-slices オプションの説明を参照してください。

有効なフラグメントレプリカからの読取り.  NDB 8.0.19 以降では、すべての NDB テーブルでフラグメントレプリカからの読み取りがデフォルトで有効になっています。 これは、ndb_read_backup システム変数のデフォルト値が ON になり、新しい NDB テーブルの作成時に NDB_TABLE コメントオプション READ_BACKUP の値が 1 になることを意味します。 フラグメントレプリカからの読取りを有効にすると、書込みへの影響を最小限に抑えながら、NDB テーブルからの読取りのパフォーマンスが大幅に向上します。

詳細は、ndb_read_backup システム変数および セクション13.1.20.11「NDB_TABLE オプションの設定」 の説明を参照してください。

ndb_blob_tool の拡張機能.  NDB 8.0.20 以降、ndb_blob_tool ユーティリティーはインラインパートが存在する欠落している BLOB パートを検出し、それらを正しい長さのプレースホルダー BLOB パート (スペース文字で構成される) に置き換えることができます。 BLOB 部分が欠落しているかどうかを確認するには、このプログラムで --check-missing オプションを使用します。 欠落している BLOB 部分をプレースホルダに置き換えるには、--add-missing オプションを使用します。

詳細は、セクション23.4.6「ndb_blob_tool — NDB Cluster テーブルの BLOB および TEXT カラムのチェックおよび修復」を参照してください。

ndbinfo バージョニング.  NDB 8.0.20 以降では、ndbinfo テーブルのバージョニングがサポートされ、そのテーブルの現在の定義が内部的に保持されます。 起動時に、NDB はサポートされている ndbinfo バージョンをデータディクショナリに格納されているバージョンと比較します。 バージョンが異なる場合、NDB は古い ndbinfo テーブルを削除し、現在の定義を使用して再作成します。

Fedora Linux のサポート.  NDB 8.0.20 以降、Fedora Linux は NDB Cluster コミュニティリリースでサポートされているプラットフォームであり、Oracle がこの目的で提供する RPM を使用してインストールできます。 これらは「NDB Cluster のダウンロードページ」から取得できます。

NDB プログラム -NDBT 依存関係の削除.  多数の NDB ユーティリティプログラムの NDBT ライブラリへの依存性が削除されました。 このライブラリは開発用に内部的に使用され、通常の使用には必要ありません。これらのプログラムに含めると、テスト時に不要な問題が発生する可能性があります。

影響を受けるプログラムを、依存関係が削除された NDB バージョンとともに次に示します:

ユーザーに対するこの変更の主な影響は、これらのプログラムが実行の完了後に NDBT_ProgramExit - status を印刷しなくなることです。 このような動作に依存するアプリケーションは、示されたバージョンにアップグレードするときに変更を反映するように更新する必要があります。

外部結合および準結合のプッシュダウン.  NDB 8.0.20 で実行される作業では、主キーまたは一意キー検索を使用するものだけでなく、多くの外部結合および準結合をデータノードにプッシュダウンできます (セクション8.2.1.5「エンジンコンディションプッシュダウンの最適化」 を参照)。

プッシュできるようになったスキャンを使用した外部結合には、次の条件を満たす外部結合が含まれます:

インデックススキャンを使用する準結合は、プッシュされた外部結合で示された条件を満たし、firstMatch 戦略を使用する場合にプッシュできるようになりました (セクション8.2.2.1「準結合変換による IN および EXISTS サブクエリー述語の最適化」 を参照)。

結合をプッシュできない場合、EXPLAIN は理由を指定する必要があります。

外部キーと大文字小文字の区別.  NDB では、定義された大/小文字を使用して外部キーの名前が格納されます。 以前は、lower_case_table_names システム変数の値が 0 に設定されていた場合、SELECT で使用されている外部キー名と格納されている名前を持つ他の SQL ステートメントとの大/小文字を区別した比較が実行されていました。 NDB 8.0.20 以降、このような比較は、lower_case_table_names の値に関係なく、常に大文字と小文字を区別しない方法で実行されるようになりました。

複数のトランスポータ.  NDB 8.0.20 では、データノードのペア間のノード間通信を処理するための複数のトランスポータのサポートが導入されています。 これにより、クラスタ内の各ノードグループに対する更新操作の速度が向上し、単一ソケットを使用したノード間通信に対するシステムまたはその他の制限による制約を回避できます。

デフォルトでは、NDB は、ローカルデータ管理 (LDM) スレッドの数またはトランザクションコーディネータ (TC) スレッドの数 (いずれか大きい方) に基づいて、多数のトランスポータを使用するようになりました。 デフォルトでは、トランスポータの数はこの数の半分です。 ほとんどのワークロードではデフォルトのパフォーマンスが適切ですが、NodeGroupTransporters データノード構成パラメータ (NDB 8.0.20 でも導入されています) を LDM スレッドの最大数または TC スレッドの数まで設定することで、各ノードグループで使用されるトランスポータの数を調整できます。 0 に設定すると、トランスポータの数は LDM スレッドの数と同じになります。

ndb_restore: 主キースキーマの変更.  NDB 8.0.21 (以降) は、--allow-pk-changes オプションを指定して実行されたときに ndb_restore を使用して NDB ネイティブバックアップを復元するときに、ソーステーブルとターゲットテーブルに対して異なる主キー定義をサポートします。 元の主キーを構成するカラム数の増減がサポートされています。

主キーが追加のカラムで拡張されている場合、追加されたカラムは NOT NULL として定義する必要があり、そのようなカラムの値はバックアップの取得中に変更できません。 一部のアプリケーションでは、更新時に行のすべてのカラム値が設定されるため、すべての値が実際に変更されているかどうかにかかわらず、主キーに追加されるカラムの値が変更されていなくてもリストア操作が失敗する可能性があります。 --ignore-extended-pk-updates オプションを使用して、この動作をオーバーライドできます (こちらも NDB 8.0.21 で追加)。この場合、このような値が変更されていないことを確認する必要があります。

このカラムがテーブルの一部であるかどうかにかかわらず、テーブルの主キーからカラムを削除できます。

詳細は、ndb_restore の --allow-pk-changes オプションの説明を参照してください。

ndb_restore とのバックアップのマージ.  場合によっては、NDB Cluster の異なるインスタンス (すべて同じスキーマを使用) に格納されていたデータを単一のターゲット NDB Cluster に統合することが望ましいことがあります。 これは、NDB 8.0.21 で --restore-data とともに追加された --remap-column オプションを使用して、ndb_mgm クライアント (セクション23.5.8.2「NDB Cluster 管理クライアントを使用したバックアップの作成」 を参照) で作成されたバックアップを使用し、ndb_restore でそれらを復元するときにサポートされるようになりました (さらに、必要に応じて互換性のある追加オプションもあります)。--remap-column を使用すると、主キー値と一意キー値がソースクラスタ間で重複しているケースを処理できます。また、外部キーなどのテーブル間の他の関係を保持するために、ターゲットクラスタで重複しないようにする必要があります。

--remap-column は、その引数として db.tbl.col:fn:args という形式の文字列を取ります。ここで、db、tbl および col はそれぞれ、データベース、テーブルおよびカラムの名前、fn は再マッピング関数の名前、args は fn への 1 つ以上の引数です。 デフォルト値はありません。 関数名として offset のみがサポートされ、バックアップからターゲットテーブルに挿入するときにカラムの値に適用される整数オフセットとして args が使用されます。 このカラムは、INT または BIGINT のいずれかである必要があります。オフセット値の許容範囲は、そのタイプの符号付きバージョンと同じです (これにより、必要に応じてオフセットを負にできます)。

ndb_restore の同じ起動で新しいオプションを複数回使用できるため、同じテーブルまたは異なるテーブル (あるいはその両方) の新しい値を複数のカラムに再マップできます。 オフセット値は、オプションのすべてのインスタンスで同じである必要はありません。

さらに、NDB 8.0.21 からも、ndb_desc 用に 2 つの新しいオプションが提供されています:

詳細および例については、--remap-column オプションの説明を参照してください。

スレッド改善の送信.  NDB 8.0.20 の時点では、各送信スレッドがトランスポータのサブセットへの送信を処理するようになり、各ブロックスレッドは 1 つの送信スレッドのみを支援するようになったため、より多くの送信スレッドが生成されるため、パフォーマンスとデータノードのスケーラビリティーが向上します。

SpinMethod を使用した適応スピン制御.  NDB 8.0.20 では、SpinMethod データノードパラメータを使用して、それをサポートするプラットフォームで適応 CPU スピンを設定するための単純なインタフェースが導入されています。 このパラメータには 4 つの設定があり、それぞれ静的スピン用、コストベースの適応スピン用、待機時間最適化された適応スピン用、および各スレッドが独自の CPU を持つデータベースマシン用に最適化された適応スピン用です。 これらの各設定により、データノードは 1 つまたは複数のスピンパラメータに事前定義された値のセットを使用し、適応スピンを有効にし、スピンタイミングを設定し、スピンオーバーヘッドを特定のシナリオに応じて設定するため、一般的なユースケースでこれらを直接設定する必要がなくなります。

スピン動作を微調整するには、既存の SchedulerSpinTimer データノード構成パラメータおよび ndb_mgm クライアントの次の DUMP コマンドを使用して、これらのスピンパラメータと追加のスピンパラメータを直接設定することもできます:

NDB 8.0.20 は、指定された TCP 接続に対してスピンする時間を設定する新しい TCP 構成パラメータ TcpSpinTime も追加します。

ndb_top ツールは、スレッドごとにスピン時間情報を提供するように拡張されています。

詳細は、SpinMethod パラメータ、リストされている DUMP コマンドおよび セクション23.4.29「ndb_top — NDB スレッドの CPU 使用率情報の表示」 の説明を参照してください。

ディスクデータとクラスタの再起動.  NDB 8.0.21 以降では、クラスタを最初に再起動すると、テーブルスペースやログファイルグループなどのすべてのディスクデータオブジェクト (これらのオブジェクトに関連付けられたデータファイルや undo ログファイルを含む) が強制的に削除されます。

詳細は、セクション23.5.10「NDB Cluster ディスクデータテーブル」を参照してください。

ディスクデータエクステント割当て.  NDB 8.0.20 以降では、データファイル内のエクステントの割り当ては、特定のテーブルスペースで使用されるすべてのデータファイル間でラウンドロビン方式で行われます。 これは、ディスクデータストレージに複数のストレージデバイスが使用されている場合に、データの分散を改善することが期待されます。

詳細は、セクション23.5.10.1「NDB Cluster ディスクデータオブジェクト」を参照してください。

--ndb-log-fail-terminate オプション.  NDB 8.0.21 以降では、すべての行イベントを完全にログに記録できない場合は常に SQL ノードを終了させることができます。 これを行うには、--ndb-log-fail-terminate オプションを指定して mysqld を起動します。

AllowUnresolvedHostNames パラメータ.  デフォルトでは、管理ノードは、グローバル構成ファイルに存在するホスト名を解決できない場合に起動を拒否します (Kubernetes などの一部の環境で問題が発生する可能性があります)。 NDB 8.0.22 以降では、クラスタグローバル会議ファイル (config.ini ファイル) の[tcp default]セクションで AllowUnresolvedHostNames を true に設定することによって、この動作をオーバーライドできます。 これにより、そのようなエラーはかわりに警告として処理され、ndb_mgmd の起動を続行できます

BLOB 書込みパフォーマンスの向上.  NDB 8.0.22 は、同じ行で複数の BLOB カラムを変更するとき、または同じステートメントで BLOB カラムを含む複数の行を変更するときに、これらの変更を適用するときに SQL またはほかの API ノードとデータノードの間で必要なラウンドトリップ数を減らすことによって、より効率的なバッチ処理を可能にする多数の改善を実装しています。 したがって、多くの INSERT、UPDATE および DELETE ステートメントのパフォーマンスを向上させることができます。 このようなステートメントの例を次に示します。table は、1 つ以上の BLOB カラムを含む NDB テーブルです:

他の SQL ステートメントでも、これらの改善のメリットが得られる場合があります。 これには、LOAD DATA INFILE および CREATE TABLE ... SELECT ... が含まれます。 また、table がステートメントの実行前に NDB 以外のストレージエンジンを使用する ALTER TABLE table ENGINE = NDB も、より効率的に実行できます。

この拡張機能は、MySQL タイプ BLOB, MEDIUMBLOB, LONGBLOB, TEXT, MEDIUMTEXT および LONGTEXT のカラムに影響するステートメントに適用されます。 TINYBLOB カラムまたは TINYTEXT カラム (あるいはその両方) のみを更新するステートメントは、この作業の影響を受けないため、パフォーマンスは変更されません。

バッチ処理を分割するテーブル Blob カラムのスキャンが必要なため、一部の SQL ステートメントのパフォーマンスはこの拡張によって大幅に向上しません。 このようなステートメントには、次に示すタイプのステートメントが含まれます:

この改善を最大限に活用するために、mysqld の --ndb-batch-size および --ndb-blob-write-batch-bytes オプションに使用される値を増やして、BLOB の変更に必要なラウンドトリップの回数を最小限に抑えることができます。 レプリケーションの場合は、slave_allow_batching システム変数を有効にすることもお薦めします。これにより、エポックトランザクションを適用するためにレプリカクラスタで必要なラウンドトリップの回数が最小限に抑えられます。

Node.js の更新.  NDB 8.0.22 以降、NDB Adapter for Node.js はバージョン 12.18.3 を使用して構築され、そのバージョン (またはそれ以降のバージョンの Node.js) のみがサポートされるようになりました。

暗号化バックアップ.  NDB 8.0.22 では、AES-256-CBC を使用して暗号化されたバックアップファイルのサポートが追加されています。これは、未承認のパーティによってアクセスされたバックアップからのデータの回復から保護することを目的としています。 暗号化すると、バックアップデータはユーザー指定のパスワードによって保護されます。 パスワードには、!, ', ", $, %, \および ^ 以外の印刷可能な ASCII 文字の範囲から 256 文字までの任意の文字列を指定できます。 指定された NDB Cluster バックアップの暗号化に使用されるパスワードの保持は、ユーザーまたはアプリケーションが実行する必要があります。NDB はパスワードを保存しません。 パスワードは空にできますが、これはお薦めしません。

NDB Cluster のバックアップを作成するときは、管理クライアントの START BACKUP コマンドで ENCRYPT PASSWORD=password を使用して暗号化できます。 MGM API のユーザーは、ndb_mgm_start_backup4() をコールして暗号化バックアップを開始することもできます。

暗号化バックアップからリストアするには、--decrypt および --backup-password オプションを指定して ndb_restore を使用します。 両方のオプションと、暗号化されていない場合に同じバックアップをリストアするために必要なその他のオプションが必要です。ndb_print_backup_file および ndbxfrm は、それぞれ -P password および --decrypt-password= password を使用して、暗号化されたファイルを読み取ることもできます。

暗号化または復号化のためにパスワードを指定する場合は、すべて引用符で囲む必要があります。パスワードを区切るには、一重引用符または二重引用符を使用できます。

8.0.22 リリースで NDB Cluster ディストリビューションに追加された ndbxfrm ユーティリティーを使用して、既存のバックアップファイルを暗号化できます。このプログラムは、暗号化されたバックアップファイルの復号化にも使用できます。 さらに、CompressedBackup 構成パラメータが 1 に設定されている場合、ndbxfrm は NDB Cluster がバックアップの作成に使用するのと同じ方法を使用して、バックアップファイルを圧縮し、圧縮されたバックアップファイルを解凍できます。

この機能は、クラスタグローバル構成ファイルの[ndbd default]セクションで RequireEncryptedBackup=1 を設定することで、暗号化バックアップを強制する機能も実装します。 これが行われると、ndb_mgm クライアントは暗号化されていないバックアップの実行を拒否します。

IPv6 のサポート.  NDB 8.0.22 以降、IPv6 アドレス指定は、管理ノードおよびデータノードへの接続でサポートされます。これには、管理ノードと SQL ノードを持つデータノード間の接続が含まれます。 クラスタを構成する場合、数値の IPv6 アドレス、IPv6 アドレスに解決されるホスト名、またはその両方を使用できます。

IPv6 アドレス指定が機能するには、クラスタがデプロイされているオペレーティングプラットフォームおよびネットワークで IPv6 がサポートされている必要があります。 IPv4 アドレス指定を使用する場合と同様に、IPv6 アドレスへのホスト名解決はオペレーティングプラットフォームによって提供される必要があります。

IPv4 アドレス指定は、引き続き NDB でサポートされます。 IPv4 アドレスと IPv6 アドレスを同時に使用することはお薦めしませんが、次の場合に機能するようにできます:

これらのケースは、ndb_mgmd がデフォルトではどの IP アドレスにもバインドしないため機能します。

IPv6 アドレス指定をサポートしていないバージョンの NDB からそのバージョンへのアップグレードを実行するには、ネットワークで IPv4 および IPv6 がサポートされている場合、まずソフトウェアのアップグレードを実行します。これが完了したら、config.ini ファイルで使用されている IPv4 アドレスを IPv6 アドレスで更新できます。 その後、構成の変更を有効にし、IPv6 アドレスを使用してクラスタを起動するには、クラスタのシステム再起動を実行する必要があります。

自動インストーラの非推奨および削除.  MySQL NDB Cluster Auto-Installer web ベースのインストールツール (ndb_setup.py) は NDB 8.0.22 では非推奨であり、NDB 8.0.23 以降では削除されます。 サポートされなくなりました。

ndbmemcache の非推奨および削除.  ndbmemcache はサポートされなくなりました。ndbmemcache は NDB 8.0.22 で非推奨になり、NDB 8.0.23 で削除されました。

ndbinfo backup_id テーブル.  NDB 8.0.24 は、backup_id テーブルを ndbinfo 情報データベースに追加します。 これは、ndb_select_all を使用して内部 SYSTAB_0 入力可能オブジェクトの内容をダンプすることで、この情報を取得するための代替手段として機能します。これはエラーが発生しやすく、実行に非常に時間がかかります。

このテーブルには、START BACKUP 管理クライアントコマンドを使用して取得されたクラスタの最新のバックアップの ID を含む単一のカラムおよび行があります。 このクラスタのバックアップが見つからない場合、テーブルにはカラム値が 0 の単一行が含まれます。

テーブルのパーティション化の拡張機能.  NDB 8.0.23 には、テーブルのパーティションおよびフラグメントを処理するための新しい方法が導入されており、これにより、REDO ログ部分の数に関係なく、特定のデータノードのローカルデータマネージャー (LDM) の数を決定できます。 これは、LDM の数が大きく変動する可能性があることを意味します。 NDB は、NDB 8.0.23 にも実装されている ClassicFragmentation データノード構成パラメータが false に設定されている場合にこの方法を使用できます。この場合、LDM の数はデータノードごとのテーブルに作成するパーティションの数を決定するために使用されなくなり、PartitionsPerNode パラメータの値 (NDB 8.0.23 にも導入されています) によってこの数が代わりに決定され、テーブルに使用されるフラグメントの数の計算にも使用されます。

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

詳細は、マルチスレッドの構成パラメータ (ndbmtd) で前述の新しいパラメータの説明を参照してください。

用語の更新.  NDB 8.0.23 は、MySQL 8.0.21 および NDB 8.0.21 で開始された作業に合わせて、次に示す用語の多くの変更を実装します:

ThreadConfig の拡張機能.  NDB 8.0.23 の時点で、ThreadConfig パラメータの構成可能性は、次に示す 2 つの新しいスレッドタイプで拡張されています:

次のいずれかの方法で、既存の main スレッドと rep スレッドを組み合せることもできます:

また、既存のスレッドタイプの最大数が増加しました。 クエリースレッドおよびリカバリスレッドの最大値を含む新しい最大値を次に示します:

その他のスレッドタイプの最大値は変更されません。

詳細は、ThreadConfig パラメータおよび ndbinfo.threads テーブルの説明を参照してください。

また、このタスクに関連して実行された作業の結果、NDB では、32 を超えるブロックスレッドを使用する場合に mutex を使用してジョブバッファを保護するようになりました。 これにより、パフォーマンスがわずかに低下する可能性がありますが (ほとんどの場合、1 から 2 パーセント)、非常に大規模な構成に必要なメモリー量も大幅に減少します。 たとえば、NDB 8.0.23 より前の 2 G バイトのジョブバッファーメモリーを使用する 64 スレッドの設定では、NDB 8.0.23 以降では約 1 G バイトのみが必要です。 このテストでは、非常に複雑なクエリーの実行で全体的に 5 パーセントの順序で改善されました。

ndbmtd スレッドの自動構成.  NDB 8.0.23 以降では、ndbmtd 構成パラメータ AutomaticThreadConfig を使用して、マルチスレッドデータノードのスレッドの自動構成を使用できます。 このパラメータが 1 に設定されている場合、NDB は、アプリケーションで使用可能なプロセッサの数に基づいて、前の項目で説明した新しい query および recover スレッドタイプを含む、すべてのスレッドでサポートされるスレッドタイプのスレッド割当てを自動的に設定します。 システムがプロセッサの数を制限しない場合は、必要に応じて NumCPUs を設定することで制限できます (こちらも NDB 8.0.23 で追加)。 それ以外の場合、自動スレッド構成は最大 1024 個の CPU に対応します。

自動スレッド構成は、config.ini で ThreadConfig または MaxNoOfExecutionThreads に設定された値に関係なく行われます。つまり、これらのパラメータのいずれも設定する必要はありません。

さらに、NDB 8.0.23 は、ハードウェアと CPU の可用性に関する情報を提供する多くの新しい ndbinfo 情報データベーステーブル、および NDB データノードによる CPU 使用率を実装しています。 これらのテーブルは次のとおりです:

NDB Cluster でサポートされているすべてのプラットフォームでこれらのテーブルの一部を使用できるわけではありません。詳細は、それらの個々の説明を参照してください。

NDB データベースオブジェクトの階層ビュー.  NDB 8.0.24 の ndbinfo 情報データベースに追加された dict_obj_tree テーブルは、次のような多くの NDB データベースオブジェクトの階層およびツリー形式のビューを提供できます:

詳細および例については、セクション23.5.14.22「ndbinfo dict_obj_tree テーブル」を参照してください。