MySQL :: MySQL 8.0 リファレンスマニュアル :: 23.1.4 NDB Cluster の新機能

9.4 English
9.3 English
9.2 English
9.1 English
9.0 English
8.4 English
8.0 English
5.7 English

MySQL 8.0 リファレンスマニュアル / ... / NDB Cluster の新機能

このページは機械翻訳したものです。

23.1.4 NDB Cluster の新機能

次のセクションでは、以前のリリースシリーズと比較して、8.0.23 を介した MySQL NDB Cluster 8.0 での NDB Cluster の実装の変更点について説明します。 NDB Cluster 8.0 は、NDB 8.0.19 以降の General Availability (GA) リリースとして使用できます。 NDB Cluster 7.6 および 7.5 は、本番で引き続きサポートされている以前の GA リリースです。NDB Cluster 7.6 については、What is New in NDB Cluster 7.6 を参照してください。 NDB Cluster 7.5 に関する同様の情報については、What is New in NDB Cluster 7.5 を参照してください。 NDB Cluster 7.4 および 7.3 は以前の GA リリースで本番で引き続きサポートされていますが、本番用の新しい配備では NDB Cluster 8.0 を使用することをお勧めします。MySQL NDB Cluster 7.3 and NDB Cluster 7.4 を参照してください。

NDB Cluster 8.0 の新機能

関心のある NDB Cluster 8.0 の主な変更点と新機能を次のリストに示します:

互換性の強化. 次の変更により、他の MySQL ストレージエンジンと比較して、NDB の動作における重要でない長期的な違いが軽減されます:
- MySQL サーバーと並行した開発. このリリース以降、MySQL NDB Cluster は、次の機能を備えた新しい統合リリースモデルで、標準の MySQL 8.0 サーバーと並行して開発されています:
  - NDB 8.0 は、MySQL 8.0 ソースコードツリーで開発、構築、およびリリースされます。
  - NDB Cluster 8.0 リリースの番号スキームは、バージョン 8.0.13 以降の MySQL 8.0 のスキームに従います。
  - NDB サポートを使用してソースを構築すると、次に示すように、mysql -V によって返されるバージョン文字列に -cluster が追加されます:
    
    Press CTRL+C to copy
    
    shell≫ mysql -V mysql Ver 8.0.23-cluster for Linux on x86_64 (Source distribution)
    
    NDB バイナリには、次のように MySQL Server バージョンと NDB エンジンバージョンの両方が引き続き表示されます:
    
    Press CTRL+C to copy
    
    shell> ndb_mgm -V MySQL distrib mysql-8.0.23 ndb-8.0.23, for Linux (x86_64)
    
    MySQL Cluster NDB 8.0 では、これらの 2 つのバージョン番号は常に同じです。
  NDB Cluster をサポートする MySQL 8.0.13 (またはそれ以降) ソースを構築するには、CMake オプション -DWITH_NDBCLUSTER を使用します。
- プラットフォームサポートノート. NDB 8.0 は、プラットフォームサポートで次の変更を行います:
  - NDBCLUSTER では、32-bit プラットフォームはサポートされなくなりました。 NDB 8.0.21 以降、NDB 構築プロセスはシステムアーキテクチャーをチェックし、64 ビットプラットフォームでない場合は中止します。
  - NDB 8.0.18 以降では、64 ビット ARM CPU のソースから NDB を構築できます。現在、このサポートはソースのみであり、このプラットフォームにプリコンパイルされたバイナリは提供されていません。
- データベース名とテーブル名. NDB 8.0.18 の時点では、データベースおよびテーブルの識別子に対する 63 バイトの制限が削除されます。これらの識別子は、ほかの MySQL ストレージエンジンを使用するオブジェクトの場合と同様に、最大 64 バイトを使用できるようになりました。セクション23.1.7.11「前 NDB Cluster 8.0 で解決される NDB Cluster の問題」を参照してください。
- 外部キーに対して生成された名前. NDB (バージョン 8.0.18 以降) では、内部的に生成された外部キーの命名にパターン tbl_name_fk_N が使用されるようになりました。これは、InnoDB で使用されるパターンに似ています。
スキーマとメタデータの分散および同期. NDB 8.0 では、MySQL データディクショナリを使用して、クラスタに参加している SQL ノードにスキーマ情報を分散し、既存の SQL ノード間で新しいスキーマ変更を同期します。次のリストでは、この統合作業に関連する個々の拡張機能について説明します:
- スキーマ分散の拡張機能. スキーマ操作を処理し、その進行状況を追跡する NDB スキーマ配布コーディネータは NDB 8.0.17 で拡張され、スキーマ操作中に使用されるリソースがその最後に解放されるようになりました。以前は、この作業の一部はスキーマ分散クライアントによって実行されていました。これは、クライアントに必ずしもすべての必要な状態情報がないために変更されており、クライアントが完了前にコーディネータに通知せずにスキーマ操作を破棄することを決定した場合、リソースリークが発生する可能性がありました。
  
  この問題を修正するために、スキーマ操作のタイムアウト検出がスキーマ配布クライアントからコーディネータに移動され、スキーマ操作中に使用されたリソースをクリーンアップする機会がコーディネータに提供されました。コーディネータは、進行中のスキーマ操作のタイムアウトを定期的にチェックし、タイムアウトの検出時に、指定されたスキーマ操作をまだ完了していない参加者を失敗としてマークします。また、スキーマ操作のタイムアウトが発生するたびに適切な警告が表示されます。 (このようなタイムアウトが検出されると、スキーマ操作自体が続行されることに注意してください。) 追加のレポートは、アクティブなスキーマ操作のリストを、これらの操作の進行中に定期的に出力することによって行われます。
  
  この作業の追加部分として、新しい mysqld オプション --ndb-schema-dist-timeout を使用すると、スキーマ操作がタイムアウトとマークされるまで待機する時間の長さを設定できます。
- ディスクデータファイルの分散. NDB Cluster 8.0.14 以降、NDB は MySQL データディクショナリを使用して、ディスクデータファイルおよび関連する構成 (テーブルスペースやログファイルグループなど) が、接続されているすべての SQL ノード間で正しく分散されていることを確認します。
- テーブルスペースオブジェクトのスキーマ同期. MySQL Server は、SQL ノードとして NDB クラスタに接続するときに、そのデータディクショナリを NDB ディクショナリにある情報と照合してチェックします。
  
  以前は、新しい SQL ノードの接続時に同期された NDB オブジェクトはデータベースとテーブルだけでした。MySQL NDB Cluster 8.0.14 以降では、テーブルスペースやログファイルグループを含むディスクデータオブジェクトのスキーマ同期も実装されていました。これにより、テーブルスペースおよびログファイルグループが MySQL Server データディクショナリではなく NDB ディクショナリにリストアされたネイティブのバックアップおよびリストア後に、MySQL データディクショナリと NDB ディクショナリの間で不一致が発生する可能性がなくなります。
  
  存在しないテーブルスペースを参照する CREATE TABLE ステートメントを発行することもできなくなりました。このようなステートメントはエラーで失敗します。
- データベース DDL 同期の拡張機能. NDB 8.0.17 で行われた作業により、新しく結合 (または再結合) された SQL ノードと既存の SQL ノード上のデータベースの同期がデータディクショナリを適切に使用するようになり、この SQL ノードで見逃された可能性のあるデータベースレベルの操作 (CREATE DATABASE、ALTER DATABASE または DROP DATABASE) がクラスタに接続 (または再接続) されたときに正しく複製されるようになりました。
  
  起動時に実行されるスキーマ同期化プロシージャの一部として、SQL ノードはクラスタデータノード上のすべてのデータベースを独自のデータディクショナリ内のデータベースと比較するようになり、これらのいずれかが SQL ノードデータディクショナリから欠落していることが判明した場合、SQL ノードは CREATE DATABASE ステートメントを実行してローカルにインストールします。このように作成されたデータベースでは、ステートメントの実行時にこの SQL ノードで有効なデフォルトの MySQL Server データベースプロパティ (character_set_database や collation_database によって決定されるものなど) が使用されます。
- NDB メタデータ変更の検出および同期. NDB 8.0.16 は、MySQL データディクショナリを使用して、テーブル、テーブルスペース、ログファイルグループなどのデータオブジェクトのメタデータの更新を検出するための新しいメカニズムを実装しています。これは、バックグラウンドで実行され、NDB ディクショナリと MySQL データディクショナリの間の不整合を定期的にチェックする NDB メタデータ変更モニタースレッドであるスレッドを使用して行われます。
  
  モニターは、デフォルトで 60 秒ごとにメタデータチェックを実行します。ポーリング間隔を調整するには、ndb_metadata_check_interval システム変数の値を設定します。ポーリングを完全に無効にするには、ndb_metadata_check システム変数を OFF に設定します。ステータス変数 (こちらも NDB 8.0.16 で追加) Ndb_metadata_detected_count は、mysqld が最後に起動されてから不一致が検出された回数を示します。
  
  バージョン 8.0.18 以降、NDB では、起動後の操作中にメタデータチェンジモニタースレッドによって発行された NDB テーブル、ログファイルグループおよびテーブルスペースオブジェクトの不一致が自動的にチェックされ、NDB binlog スレッドによって同期化されます。
  
  NDB 8.0.18 は、自動同期に関連する 2 つのステータス変数も追加: Ndb_metadata_synced_count には、自動的に同期されたオブジェクトの数が表示されます。Ndb_metadata_excluded_count は、同期が失敗したオブジェクトの数を示します (NDB 8.0.22 より前では、この変数の名前は Ndb_metadata_blacklist_size でした)。また、どのオブジェクトが同期化されているかを確認するには、クラスタログを調べます。
  
  NDB 8.0.19 は、変更が検出および同期されるオブジェクトにデータベースを追加することによって、この機能をさらに強化します。 NDB テーブルで実際に使用されるデータベースのみが処理され、MySQL データディクショナリに存在する可能性のある他のデータベースは無視されます。これにより、このデータベースを手動で作成するために、NDB にテーブルが存在していても、それが属するテーブルおよびデータベースが SQL ノードに存在しない場合に、以前の要件がなくなります。このような場合は、データベースおよびそれに属するすべての NDB テーブルを SQL ノードに自動的に作成する必要があります。
  
  NDB 8.0.19 では、ndb_metadata_sync システム変数も導入されています。この変数を true に設定すると、ndb_metadata_check_interval および ndb_metadata_check に対して行われたすべての設定がオーバーライドされ、変更モニタースレッドが連続したメタデータ変更検出を開始します。
  
  NDB 8.0.22 以降では、ndb_metadata_sync を true に設定すると、以前に同期が失敗したオブジェクトのリストがクリアされるため、個々のテーブルを検出したり、SQL ノードをクラスタに再接続して同期を再トリガーしたりする必要がなくなります。また、この変数を false に設定すると、再試行を待機しているオブジェクトのリストがクリアされます。
  
  NDB 8.0.21 以降、ログメッセージまたはステータス変数から取得できる自動同期の現在の状態に関する詳細情報は、MySQL パフォーマンススキーマに追加された 2 つの新しいテーブルによって提供されます。テーブルは次のとおりです:
  - ndb_sync_pending_objects: NDB ディクショナリと MySQL データディクショナリの間で不一致が検出された (および自動同期から除外されていない) データベースオブジェクトに関する情報が含まれます。
  - ndb_sync_excluded_objects: 除外された NDB データベースオブジェクトに関する情報が含まれます。これらのオブジェクトは、NDB ディクショナリと MySQL データディクショナリの間で同期できないため、手動操作が必要になります。
  これらのテーブルのいずれかの行には、データベースオブジェクトの親スキーマ、名前およびタイプが示されます。オブジェクトのタイプには、スキーマ、テーブルスペース、ログファイルグループおよびテーブルがあります。 (オブジェクトがログファイルグループまたはテーブルスペースの場合、親スキーマは NULL です。) また、ndb_sync_excluded_objects テーブルには、オブジェクトが除外された理由が表示されます。
  
  これらのテーブルは、NDBCLUSTER ストレージエンジンのサポートが有効になっている場合にのみ存在します。これらのテーブルの詳細は、セクション27.12.12「パフォーマンススキーマ NDB Cluster テーブル」を参照してください。
- NDB テーブルの追加メタデータの変更. NDB 8.0.14 以降では、NDB テーブルの追加のメタデータプロパティーは、以前のバージョンと同様にテーブルのバイナリ表現を格納するのではなく、MySQL データディクショナリから直列化されたメタデータを格納するために使用されます。 (これは .frm ファイルであり、MySQL Server-see 第14章「MySQL データディクショナリ」では使用されなくなりました。) この変更をサポートする作業の一環として、テーブルの追加メタデータの使用可能なサイズが増加しました。つまり、NDB Cluster 8.0.14 以降で作成された NDB テーブルは、以前の NDB Cluster リリースと互換性がありません。以前のリリースで作成されたテーブルは NDB 8.0.14 以降で使用できますが、それより前のバージョンで開くことはできません。
  
  このメタデータには、NDB 8.0.13 で実装された NDB API メソッド getExtraMetadata() および setExtraMetadata() を使用してアクセスできます。
  
  詳細は、セクション23.2.7「NDB Cluster のアップグレードおよびダウングレード」を参照してください。
- .frm ファイルを使用したテーブルのオンザフライアップグレード. NDB 7.6 以前で作成されたテーブルには、MySQL 8.0 ではサポートされなくなった圧縮 .frm ファイルの形式でメタデータが含まれています。 NDB 8.0 へのオンラインアップグレードを容易にするために、NDB はこのメタデータのオンザフライ変換を実行し、MySQL Server データディクショナリに書き込みます。これにより、NDB Cluster 8.0 内の mysqld は、以前のバージョンの NDB ソフトウェアによるテーブルの以降の使用を妨げずにテーブルを操作できます。
  
  重要
  
  NDB 8.0 でテーブル構造が変更されると、そのメタデータはデータディクショナリを使用して格納され、NDB 7.6 以前からはアクセスできなくなります。
  
  この拡張機能により、以前のバージョンを使用して作成された NDB バックアップを NDB 8.0 以降を実行しているクラスタに復元することもできます。
- メタデータ整合性チェックのエラーロギング. NDB 8.0 で以前に実行された作業の一部として、NDB ディクショナリ内の NDB テーブルの表現と MySQL データディクショナリ内の対応する表現との間の自動同期の一部として実行されるメタデータチェックには、テーブル名、ストレージエンジン、および内部 ID が含まれます。 NDB 8.0.23 以降、チェックされるプロパティーの範囲は、次のデータオブジェクトのプロパティーを含むように拡張されます:
  - Columns
  - インデックス
  - 外部キー
  また、メタデータプロパティの不一致の詳細が MySQL サーバーのエラーログに書き込まれるようになりました。エラーログメッセージに使用される書式は、差異がテーブルレベルで検出されるか、カラム、インデックスまたは外部キーのレベルで検出されるかによって若干異なります。テーブルレベルのプロパティーの不一致によるログエラーの形式を次に示します。ここで、property はプロパティー名、ndb_value は NDB ディクショナリに格納されているプロパティー値、mysqld_value は MySQL データディクショナリに格納されているプロパティーの値です:
```
Press CTRL+C to copy
 
Diff in 'property' detected, 'ndb_value' != 'mysqld_value'
```
  カラム、インデックスおよび外部キーのプロパティの不一致の場合、形式は次のようになります。ここで、obj_type は column、index または foreign key のいずれかで、obj_name はオブジェクトの名前です:
```
Press CTRL+C to copy
 
Diff in obj_type 'obj_name.property' detected, 'ndb_value' != 'mysqld_value'
```
  NDB Cluster 内の SQL ノードとして機能する任意の mysqld のデータディクショナリにインストールされると、NDB テーブルの自動同期中にメタデータチェックが実行されます。 mysqld がデバッグコンパイルされている場合は、CREATE TABLE ステートメントが実行されるたび、および NDB テーブルが開かれるたびにもチェックが行われます。
NDB_STORED_USER とのユーザー権限の同期. NDB 8.0.18 以降では、NDB_STORED_USER 権限を使用して、SQL ノード間でユーザー、役割、および特権を共有および同期するための新しいメカニズムを使用できます。 NDB 7.6 以前で実装された分散特権 (Distributed Privileges Using Shared Grant Tables を参照) はサポートされなくなりました。

SQL ノードでユーザーアカウントが作成されると、ユーザーとその権限を NDB に格納できるため、次のような GRANT ステートメントを発行して、クラスタ内のすべての SQL ノード間で共有できます:
```
Press CTRL+C to copy
 
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 テーブルのディスクデータファイルに関する情報の表示では、次の変更が行われます:
- テーブルスペースおよびログファイルグループは、FILES テーブルに表示されなくなりました。 (これらの構成は実際にはファイルではありません。)
- 各データファイルは、FILES テーブルの単一行でテーブルされるようになりました。各 undo ログファイルも、このテーブルでは 1 行のみでテーブルされるようになりました。 (以前は、各データノード上のこれらの各ファイルのコピーごとに行が表示されていました。)
また、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 では、次の追加の改善が行われています:
- NOT EXISTS および NOT IN クエリー (セクション8.2.2.1「準結合変換による IN および EXISTS サブクエリー述語の最適化」を参照) の変換によって MySQL オプティマイザによって生成されたアンチ結合は、NDB によってデータノードにプッシュダウンできます。
  
  これは、テーブルにプッシュされていない条件がなく、外部結合をプッシュダウンするために満たす必要がある他の条件をクエリーが満たしている場合に実行できます。
- NDB は、連結先のテーブルから行を取得する前に、非依存スカラーサブクエリーを識別および評価しようとします。その場合、取得された値は、値を提供したサブクエリーを使用するかわりに、プッシュされた条件の一部として使用されます。
最大行サイズの増加. 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_mgmd で使用されていたリストデータ構造を置き換えるため、管理サーバーの全体的な起動時間が 6 以上減少しました。
- また、管理サーバーの hosts ファイルに存在しないデータおよび SQL ノードのホスト名がクラスタ構成ファイルで使用されている場合は、ndb_mgmd の起動時間を以前のケースの 20 倍短くすることができます。
NDB API の拡張機能. NDB 8.0.18 以降では、NdbScanFilter::cmp() と NdbInterpretedCode のいくつかの比較方法を使用して、テーブルカラム値を相互に比較できます。影響を受ける NdbInterpretedCode メソッドを次に示します:
- branch_col_eq()
- branch_col_ge()
- branch_col_gt()
- branch_col_le()
- branch_col_lt()
- branch_col_ne()
前述のすべての方法で、比較されるテーブルのカラム値は、長さ、精度、符号性、スケール、文字セットおよび照合順序に関して、正確に一致する型である必要があります。

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

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

この拡張機能は、次のように実装されます:
1. BuildIndexThreads のデフォルト値は 0 から 128 に変更されています。つまり、オフライン順序付けされたインデックス構築はデフォルトでマルチスレッド化されるようになりました。
2. TwoPassInitialNodeRestartCopy のデフォルト値は、false から true に変更されました。つまり、最初のノードの再起動では、最初にすべてのデータが「「ライブ」」ノードから、インデックス構築の順序付きインデックスをオフラインで作成せずに開始しているノードにコピーされてから、そのデータがライブノードと再度同期化されます。つまり、2 回同期化され、2 つの同期化の間でオフラインでインデックスが構築されます。これにより、ノードの初期再起動はノードの通常の再起動と同様に動作し、インデックスの作成に必要な時間が短縮されます。
3. ThreadConfig 構成パラメータに新しいスレッドタイプ (idxbld) が定義され、オフラインインデックス構築スレッドを特定の CPU にロックできるようになりました。
また、NDB では、次の 2 つの基準によって ThreadConfig にアクセス可能なスレッドタイプが区別されるようになりました:
1. スレッドが実行スレッドかどうか。 main, ldm, recv, rep, tc および send タイプのスレッドは実行スレッドであり、io、watchdog および idxbld タイプは実行スレッドではありません。
2. 指定されたタスクへのスレッドの割当てが永続的か一時的か。現在、idxbld 以外のすべてのスレッドタイプは永続的です。
追加情報については、マニュアルで示されているパラメータの説明を参照してください。 (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 ハッシュ化することに基づいていました。これにより、次の理由でパフォーマンスの問題が発生する可能性があります:
- 正規化された文字列は、常に空白がその全長に埋め込まれます。 VARCHAR の場合、多くの場合、これには元の文字列の文字よりも多くのスペースの追加が含まれます。
- このスペースパディング用に文字列ライブラリが最適化されなかったため、ユースケースによってはかなりのオーバーヘッドが発生しました。
- パディングセマンティクスは文字セット間で異なり、その一部は全長までパディングされませんでした。
- 変換された文字列は、空白埋めなしでも非常に大きくなる可能性があります。Unicode 9.0 照合順序によっては、単一のコードポイントを 100 バイト以上の文字データに変換できる場合があります。
- 後続の MD5 ハッシングは主にスペースで埋めることで構成されており、特に効率的ではなかったため、L1 キャッシュの重要な部分をフラッシュすることでパフォーマンスのペナルティが増大する可能性があります。
照合には独自のハッシュ関数が用意されており、最初に正規化された文字列を作成せずに文字列を直接ハッシュします。また、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 つの点で変更されました:
- シノクロであることは保証されなくなりました。つまり、バイナリログがローテーションされるまで、RESET MASTER が発行される直前に行われる読み取りがログに記録されない可能性があります。
- バイナリログを書き込む同じ SQL ノード上でステートメントが発行されたか、同じクラスタ内の別の SQL ノード上で発行されたかにかかわらず、まったく同じように動作するようになりました。
注記

SHOW BINLOG EVENTS、FLUSH LOGS およびほとんどのデータ定義ステートメントは、以前の NDB バージョンと同様に、同期方式で動作します。
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 のトランザクションリソースを制御するいくつかの新しいデータノードパラメータが追加されました:
- ReservedConcurrentIndexOperations
- ReservedConcurrentOperations
- ReservedConcurrentScans
- ReservedConcurrentTransactions
- ReservedFiredTriggers
- ReservedLocalScans
- ReservedTransactionBufferMemory。
詳細は、前述のパラメータの説明を参照してください。
データノードごとに複数の 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 は、構成パラメータの最大値とデフォルト値を次のように変更します:
- DataMemory の最大値は 16 テラバイトに増加します。
- DiskPageBufferMemory の最大値も 16 テラバイトに増加します。
- StringMemory のデフォルト値は 25% に増加します。
- LcpScanProgressTimeout のデフォルトは 180 秒に増加します。
ディスクデータチェックポイントの改善. NDB Cluster 8.0.19 には、ソリッドステートドライブなどの不揮発性メモリーデバイスおよびそのようなデバイスの NVMe 仕様を使用する場合に、「ディスクデータ」テーブルおよびテーブルスペースのチェックポイントの待機時間を短縮するのに役立つ多くの新しい拡張機能が用意されています。これらの改善点には、次のリストの改善点が含まれます:
- チェックポイントディスク書込みのバーストの回避
- redo ログまたは undo ログがいっぱいになったときのディスクデータテーブルスペースのチェックポイントの高速化
- 必要に応じて、チェックポイントをディスクチェックポイントとインメモリーチェックポイントのバランスを調整
- 過負荷からディスクデバイスを保護し、高負荷での低レイテンシを保証
この作業の一環として、NDB 8.0.19 には 2 つの新しいデータノード構成パラメータが導入されています。 MaxDiskDataLatency では、ディスクアクセスに許可されるレイテンシの程度に上限が設定され、この時間よりもトランザクションの中断に時間がかかります。 DiskDataUsingSameDisk では、このようなテーブルスペースのチェックポイントを実行できる速度を上げることで、別々のディスク上の「ディスクデータ」テーブルスペースを利用できます。

さらに、ここに一覧表示されている ndbinfo データベース内の 3 つの新しいテーブルは、ディスクデータパフォーマンスに関する情報を提供します (こちらも NDB 8.0.19 で追加):
- diskstat テーブルは、過去 1 秒間の「ディスクデータ」テーブルスペースへの書込みについてレポート
- diskstats_1sec テーブルは、過去 20 秒間の「ディスクデータ」テーブルスペースへの書込みについてレポート
- pgman_time_track_stats テーブルには、「ディスクデータ」テーブルスペースに関連するディスク操作のレイテンシがレポートされます
メモリー割当てと TransactionMemory. NDB 8.0.19 では、トランザクションおよびローカルデータマネージャー (LDM) メモリーをプールするために実行される作業の一環として、トランザクションのデータノードメモリーの割り当てを簡略化する新しい TransactionMemory パラメータが導入されました。このパラメータは、非推奨になったいくつかの古いトランザクションメモリーパラメータを置き換えることを目的としています。

トランザクションメモリーは、次の 3 つの方法のいずれかで設定できるようになりました:
- いくつかの構成パラメータは TransactionMemory と互換性がありません。これらのいずれかが設定されている場合、TransactionMemory は設定できず (TransactionMemory と互換性のないパラメータを参照)、データノードトランザクションメモリーは NDB 8.0.19 より前の状態で決定されます。
  
  注記
  
  config.ini ファイルで TransactionMemory とこれらのパラメータを同時に設定しようとすると、管理サーバーが起動しなくなります。
- TransactionMemory が設定されている場合、この値はトランザクションメモリーの決定に使用されます。前の項目で説明した互換性のないパラメータも設定されている場合、TransactionMemory は設定できません。
- 互換性のないパラメータが設定されておらず、TransactionMemory も設定されていない場合、トランザクションメモリーは NDB によって設定されます。
詳細は、TransactionMemory およびセクション23.3.3.13「データノードのメモリー管理」の説明を参照してください。
追加のフラグメントレプリカのサポート. NDB 8.0.19 は、本番でサポートされるフラグメントレプリカの最大数を 2 から 4 に増やします。 (以前は、NoOfReplicas を 3 または 4 に設定できましたが、テストで正式にサポートまたは検証されていませんでした。)
スライスによる復元. NDB 8.0.20 以降では、ndb_restore に実装されている 2 つの新しいオプションを使用して、バックアップをほぼ同じ部分 (スライス) に分割し、これらのスライスを並列で復元できます:
- --num-slices は、バックアップを分割するスライスの数を決定します。
- --slice-id は、ndb_restore の現在のインスタンスによって復元されるスライスの ID を提供します。
これにより、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 バージョンとともに次に示します:
- ndb_restore、NDB 8.0.17
- ndb_delete_all、NDB 8.0.18
- ndb_show_tables、NDB 8.0.20
- ndb_waiter、NDB 8.0.20
ユーザーに対するこの変更の主な影響は、これらのプログラムが実行の完了後に 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 つの新しいオプションが提供されています:
- --auto-inc (ショートフォーム -a): テーブルに AUTO_INCREMENT カラムがある場合は、次の自動インクリメント値が出力に含まれます。
- --context (ショートフォーム -x): スキーマ、データベース名、テーブル名、内部 ID など、テーブルに関する追加情報を提供します。
詳細および例については、--remap-column オプションの説明を参照してください。
スレッド改善の送信. NDB 8.0.20 の時点では、各送信スレッドがトランスポータのサブセットへの送信を処理するようになり、各ブロックスレッドは 1 つの送信スレッドのみを支援するようになったため、より多くの送信スレッドが生成されるため、パフォーマンスとデータノードのスケーラビリティーが向上します。
SpinMethod を使用した適応スピン制御. NDB 8.0.20 では、SpinMethod データノードパラメータを使用して、それをサポートするプラットフォームで適応 CPU スピンを設定するための単純なインタフェースが導入されています。このパラメータには 4 つの設定があり、それぞれ静的スピン用、コストベースの適応スピン用、待機時間最適化された適応スピン用、および各スレッドが独自の CPU を持つデータベースマシン用に最適化された適応スピン用です。これらの各設定により、データノードは 1 つまたは複数のスピンパラメータに事前定義された値のセットを使用し、適応スピンを有効にし、スピンタイミングを設定し、スピンオーバーヘッドを特定のシナリオに応じて設定するため、一般的なユースケースでこれらを直接設定する必要がなくなります。

スピン動作を微調整するには、既存の SchedulerSpinTimer データノード構成パラメータおよび ndb_mgm クライアントの次の DUMP コマンドを使用して、これらのスピンパラメータと追加のスピンパラメータを直接設定することもできます:
- DUMP 104000 (SetSchedulerSpinTimerAll): すべてのスレッドのスピン時間を設定
- DUMP 104001 (SetSchedulerSpinTimerThread): 指定されたスレッドのスピン時間を設定
- DUMP 104002 (SetAllowedSpinOverhead): 1 単位の待機時間を取得できる CPU 時間の単位数としてスピンオーバーヘッドを設定
- DUMP 104003 (SetSpintimePerCall): スピンするコールの時間を設定
- DUMP 104004 (EnableAdaptiveSpinning): 患者のスピンを有効または無効にします
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 テーブルです:
- INSERT INTO table VALUES ROW(1, blob_value1, blob_value2, ...)、つまり、BLOB カラムを含む行の挿入
- INSERT INTO table VALUES ROW(1, blob_value1), ROW(2, blob_value2), ROW(3, blob_value3), ...、つまり、1 つ以上の BLOB カラムを含む複数行の挿入
- UPDATE table SET blob_column1 = blob_value1, blob_column2 = blob_value2, ...
- UPDATE table SET blob_column = blob_value WHERE primary_key_column in (value_list):主キーカラムが BLOB 型ではない場合
- DELETE FROM table WHERE primary_key_column = value:主キーカラムが BLOB 型ではない場合
- DELETE FROM table WHERE primary_key_column IN (value_list):主キーカラムが BLOB 型ではない場合
他の 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 ステートメントのパフォーマンスはこの拡張によって大幅に向上しません。このようなステートメントには、次に示すタイプのステートメントが含まれます:
- SELECT FROM table [WHERE key_column IN (blob_value_list)]: Blob 型を使用する主キーまたは一意キーカラムを照合することで行が選択されます
- UPDATE table SET blob_column = blob_value WHERE condition:一意の値に依存しない condition を使用
- 一意の値に依存しない condition を使用して、BLOB カラムを含む行を削除する DELETE FROM table WHERE condition
- ステートメントの実行前に NDB ストレージエンジンをすでに使用しており、ステートメントの実行前または実行後 (あるいはその両方) に行に BLOB カラムが含まれているテーブルに対するコピー ALTER TABLE ステートメント
この改善を最大限に活用するために、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 アドレスを同時に使用することはお薦めしませんが、次の場合に機能するようにできます:
- 管理ノードが IPv6 で構成され、データノードが config.ini ファイル内の IPv4 アドレスで構成されている場合: これは、--bind-address が mgmd で使用されておらず、--ndb-connectstring が管理ノードの IPv4 アドレスに設定された状態でデータノードが起動された場合に機能します。
- 管理ノードが IPv4 で構成され、データノードが config.ini の IPv6 アドレスで構成されている場合: 他の場合と同様に、これは、--bind-address が mgmd に渡されず、--ndb-connectstring が管理ノードの 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 で開始された作業に合わせて、次に示す用語の多くの変更を実装します:

システム変数 ndb_slave_conflict_role は非推奨になりました。 ndb_conflict_role に置き換えられています。

多くの NDB ステータス変数は非推奨です。これらの変数とその置換を次のテーブルに示します:

表 23.1 非推奨の 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`

非推奨のステータス変数は引き続き SHOW STATUS の出力に表示されますが、将来のリリースシリーズでの可用性は保証されないため、アプリケーションは依存しないようにできるかぎり早く更新する必要があります。

ndbinfo ndbinfo.table_distribution_status テーブルの tab_copy_status カラムに以前表示されていた ADD_TABLE_MASTER および ADD_TABLE_SLAVE の値は非推奨になりました。これらはそれぞれ、ADD_TABLE_COORDINATOR および ADD_TABLE_PARTICIPANT の値に置き換えられます。
ndb_restore などの一部の NDB クライアントプログラムおよびユーティリティプログラムの --help 出力が変更されました。

ThreadConfig の拡張機能. NDB 8.0.23 の時点で、ThreadConfig パラメータの構成可能性は、次に示す 2 つの新しいスレッドタイプで拡張されています:
- query: クエリースレッドは、ローカルデータマネージャ (LDM) 内で動作し、フラグメントをクエリーします。クエリースレッドは、リカバリスレッドとしても機能します。クエリースレッドの数は、LDM スレッドの数の 0、1、2、または 3 倍にする必要があります。0 (ThreadConfig を使用しない場合、または AutomaticThreadConfig が有効になっている場合、デフォルト) を指定すると、LDM は NDB 8.0.23 の前と同じように動作します。
- recover: リカバリスレッドは、ローカルチェックポイントからデータを取得します。そのように指定されたリカバリスレッドは、クエリースレッドとして機能しません。
次のいずれかの方法で、既存の main スレッドと rep スレッドを組み合せることもできます:
- これらの引数のいずれかを 0 に設定して、単一スレッドにします。これを実行すると、結果として生成される結合スレッドが ndbinfo.threads テーブルに main_rep という名前で表示されます。
- ldm と tc の両方を 0 に設定し、recv を 1 に設定することで、recv スレッドと連携します。この場合、結合されたスレッドの名前は main_rep_recv です。
また、既存のスレッドタイプの最大数が増加しました。クエリースレッドおよびリカバリスレッドの最大値を含む新しい最大値を次に示します:
- LDM: 332
- Query: 332
- Recovery: 332
- TC: 128
- Receive: 64
- Send: 64
- メイン: 2
その他のスレッドタイプの最大値は変更されません。

詳細は、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 使用率を実装しています。これらのテーブルは次のとおりです:
- cpudata
- cpudata_1sec
- cpudata_20sec
- cpudata_50ms
- cpuinfo
- hwinfo
NDB Cluster でサポートされているすべてのプラットフォームでこれらのテーブルの一部を使用できるわけではありません。詳細は、それらの個々の説明を参照してください。
NDB データベースオブジェクトの階層ビュー. NDB 8.0.24 の ndbinfo 情報データベースに追加された dict_obj_tree テーブルは、次のような多くの NDB データベースオブジェクトの階層およびツリー形式のビューを提供できます:
- テーブルおよび関連するインデックス
- テーブルスペースおよび関連するデータファイル
- ログファイルグループおよび関連する UNDO ログファイル
詳細および例については、セクション23.5.14.22「ndbinfo dict_obj_tree テーブル」を参照してください。

MySQL Cluster Manager 1.4.8 は NDB Cluster 8.0 の実験的なサポートも提供します。MySQL Cluster Manager には、多くの複雑な NDB Cluster 管理タスクを簡略化できる高度なコマンド行インタフェースがあります。詳しくはMySQL Cluster Manager 1.4.8 User Manual,をご覧ください。

PREV HOME UP NEXT