--allow-pk-changes

このオプションが 1 に設定されている場合、ndb_restore では、テーブル定義の主キーをバックアップ内の同じテーブルの主キーと異なるものにすることができます。 これは、複数のテーブルで主キーが変更されている異なるスキーマバージョン間でバックアップおよびリストアを行う場合に望ましいことがあり、テーブルスキーマおよびデータのリストア後に多くの ALTER TABLE ステートメントを発行するよりも、ndb_restore を使用してリストア操作を実行する方が単純または効率的であるようです。

--allow-pk-changes では、主キー定義の次の変更がサポートされています:

これらの違いは、ステージングテーブルの使用を必要とする BLOB カラムやテキストカラムの変更など、ndb_restore でサポートされている他のスキーマの違いと組み合せることができます。

主キースキーマの変更を使用する一般的なシナリオの基本ステップを次に示します:

主キーを拡張する場合、リストア操作中に ndb_restore で一時セカンダリ一意インデックスを使用して、古い主キーから新しい主キーにマップする必要がある場合があります。 このようなインデックスは、バックアップログから拡張主キーを持つテーブルにイベントを適用する必要がある場合にのみ作成されます。 このインデックスは NDB$RESTORE_PK_MAPPING という名前で、それを必要とする各テーブルに作成されます。必要に応じて、パラレルで実行されている ndb_restore インスタンスの複数のインスタンスで共有できます。 (リストアプロセスの最後に ndb_restore --rebuild-indexes を実行すると、このインデックスは削除されます。)

--append

--tab および --print-data オプションとともに使用すると、同じ名前の既存のファイルにデータが追加されます。

--backup-path=dir_name

バックアップディレクトリへのパスは必須です。これは、--backup-path オプションを使用して ndb_restore に提供され、リストアするバックアップの ID バックアップに対応するサブディレクトリを含める必要があります。 たとえば、データノードの DataDir が /var/lib/mysql-cluster である場合、バックアップディレクトリは /var/lib/mysql-cluster/BACKUP であり、ID 3 のバックアップのバックアップファイルは /var/lib/mysql-cluster/BACKUP/BACKUP-3 にあります。 パスは、絶対パスまたは ndb_restore 実行可能ファイルが配置されているディレクトリへの相対パスで、必要に応じて backup-path= を接頭辞として付けることができます。

作成されたデータベースとは異なる構成のデータベースにバックアップをリストアできます。 たとえば、2 および 3 というノード ID を持つ 2 つのストレージノードを持つクラスタに作成された、バックアップ ID が 12 のバックアップを、4 つのノードを持つクラスタにリストアするとします。 その後、バックアップが作成されたクラスタ内のストレージノードごとに、ndb_restore を 2 回実行する必要があります。 ただし、ndb_restore はあるバージョンの MySQL で実行されているクラスタから作成されたバックアップを、別のバージョンの MySQL で実行されているクラスタに常に復旧できるとはかぎりません。

リストアをより高速にするために、十分な数のクラスタ接続が使用できる場合は、データを並列でリストアできます。 より正確に言うと、複数のノードを並列でリストアする場合は、各並列 ndb_restore プロセスに使用できる [api] または [mysqld] セクションがクラスタ config.ini ファイルに存在する必要があります。 ただし、データファイルは常にログの前に適用する必要があります。

--backup-password=password

このオプションは、--decrypt オプションを使用して暗号化バックアップを復号化するときに使用するパスワードを指定します。 これは、バックアップの暗号化に使用されたパスワードと同じである必要があります。

パスワードは 256 文字以内で、一重引用符または二重引用符で囲む必要があります。 文字コード 32、35、38、40-91、93、95 および 97-126 を持つ ASCII 文字を含めることができます。つまり、!, ', ", $, %, \および ^ 以外の印刷可能な ASCII 文字を使用できます。

--backupid=#, -b

このオプションは、バックアップの ID または順序番号を指定するために使用され、バックアップの完了時に表示される Backup backup_id completed メッセージに管理クライアントによって表示される番号と同じです。 (セクション23.5.8.2「NDB Cluster 管理クライアントを使用したバックアップの作成」を参照してください。)

NDB 8.0.15 以降では、このオプションは必須です。

--connect, -c

--ndb-connectstring のエイリアス。

--decrypt

--backup-password オプションで指定されたパスワードを使用して、暗号化バックアップを復号化します。

--disable-indexes

ネイティブ NDB バックアップからのデータのリストア中にインデックスのリストアを無効にします。 その後、--rebuild-indexes を使用してマルチスレッドでインデックスを作成することで、すべてのテーブルのインデックスを一度にリストアできます。これは、非常に大きなテーブルのインデックスを同時に再構築するより高速である必要があります。

--dont-ignore-systab-0, -f

通常、テーブルデータおよびメタデータをリストアする場合、ndb_restore は、バックアップに存在する NDB システムテーブルのコピーを無視します。--dont-ignore-systab-0 により、システムテーブルがリストアされます。 このオプションは、実験および開発での使用のみが意図されており、本番環境には推奨されていません。

--exclude-databases=db-list

リストアしない 1 つ以上のデータベースのカンマ区切りリスト。

このオプションは、多くの場合、--exclude-tables と組み合せて使用されます。詳細および例は、そのオプションの説明を参照してください。

--exclude-intermediate-sql-tables[=TRUE|FALSE]

ALTER TABLE のコピー操作を実行するときに、mysqld は中間テーブルを作成します (名前の前に #sql- が付けられます)。 TRUE の場合、--exclude-intermediate-sql-tables オプションは、ndb_restore がこれらの操作から残された可能性のあるテーブルをリストアしないようにします。 このオプションはデフォルトでは TRUE です。

--exclude-missing-columns

このオプションを使用して、選択したテーブルのカラムのみをリストアできます。これにより、ndb_restore は、バックアップで見つかったテーブルのバージョンと比較して、リストアされるテーブルから欠落しているカラムを無視します。 このオプションはリストアされるすべてのテーブルに適用されます。 このオプションを選択したテーブルまたはデータベースにのみ適用する場合は、このセクションの他の場所で説明されている --include-* または --exclude-* のオプションと組み合せて使用し、これらのオプションの補完セットを使用して残りのテーブルにデータをリストアできます。

--exclude-missing-tables

このオプションを使用して、選択したテーブルのみをリストアできます。これにより、ndb_restore は、ターゲットデータベースで見つからないバックアップのテーブルを無視します。

--exclude-tables=table-list

除外する 1 つ以上のテーブルのリスト。各テーブル参照にはデータベース名を含める必要があります。 多くの場合、--exclude-databases とともに使用されます。

--exclude-databases または --exclude-tables を使用した場合は、これらのオプションによって指定されたデータベースまたはテーブルのみが除外されます。ほかのすべてのデータベースおよびテーブルは ndb_restore によってリストアされます。

このテーブルは、--exclude-* オプションを使用した ndb_restore のいくつかの呼び出し (わかりやすくするためにほかのオプションが省略されている可能性があります) と、これらのオプションが NDB Cluster バックアップからの復元に与える影響を示しています:

これらの 2 つのオプションは一緒に使用できます。 たとえば、次のようにすると、すべてのデータベースのすべてのテーブルが except for データベース db1 および db2 にリストアされ、データベース db3 のテーブル t1 および t2 がリストアされます:

shell> ndb_restore [...] --exclude-databases=db1,db2 --exclude-tables=db3.t1,db3.t2

(この例でも、わかりやすく簡潔にするために、必要となる可能性があるほかのオプションを省略しています)。

--include-* オプションおよび --exclude-* オプションは、次のルールに従って一緒に使用できます。

たとえば、次の一連のオプションを指定すると、ndb_restore がデータベース db1 の db1.t1 を除くすべてのテーブルをリストアし、ほかのデータベースのほかのテーブルはリストアしません。

--include-databases=db1 --exclude-tables=db1.t1

ただし、前述のオプションの順序を逆にすると、データベース db1 のすべてのテーブルがリストアされます (db1.t1 は含まれますが、ほかのデータベースのテーブルは含まれません)。これは、もっとも右にある --include-databases オプションがデータベース db1 に対して最初に一致し、db1 または db1 内のテーブルと一致するその他のオプションより優先されるためです。

--exclude-tables=db1.t1 --include-databases=db1

--fields-enclosed-by=char

各カラム値は、このオプションに渡される文字列で囲まれます (データ型に関係なく、--fields-optionally-enclosed-by の説明を参照)。

--fields-optionally-enclosed-by

このオプションに渡された文字列は、文字データが含まれているカラム値 (CHAR、VARCHAR、BINARY、TEXT、ENUM など) を囲むために使用されます。

--fields-terminated-by=char

このオプションに渡された文字列は、カラム値を区切るために使用されます。 デフォルト値はタブ文字 (\t) です。

--hex

このオプションを使用すると、すべてのバイナリ値は 16 進形式で出力されます。

--ignore-extended-pk-updates

--allow-pk-changes を使用する場合、バックアップの実行中にテーブルの主キーの一部になるカラムは更新しないでください。そのようなカラムは、値を含む行が削除されるまで、時間値から同じ値が挿入されたままにしておく必要があります。 ndb_restore がバックアップのリストア時にこれらのカラムの更新を検出すると、リストアは失敗します。 一部のアプリケーションでは、行の更新時にすべてのカラムの値が設定される場合があるため、一部のカラム値が変更されていない場合でも、実際には変更されていないカラムの更新に表示されるログイベントがバックアップに含まれることがあります。 このような場合は、--ignore-extended-pk-updates を 1 に設定して、ndb_restore でこのような更新を強制的に無視できます。

詳細は、--allow-pk-changes の説明を参照してください。

--include-databases=db-list

リストアする 1 つ以上のデータベースのカンマ区切りリスト。 多くの場合、--include-tables とともに使用されます。詳細および例は、そのオプションの説明を参照してください。

--include-stored-grants

NDB 8.0.19 以降では、ndb_restore はデフォルトで、ndb_sql_metadata テーブルへの共有ユーザーおよび権限付与 (セクション23.5.12「NDB_STORED_USER での分散 MySQL 権限」 を参照) を復元しません。 このオプションを指定すると、これが実行されます。

--include-tables=table-list

リストアするテーブルのカンマ区切りリスト。各テーブル参照にはデータベース名を含める必要があります。

--include-databases または --include-tables を使用すると、それらのオプションによって指定されたデータベースまたはテーブルのみがリストアされます。ほかのすべてのデータベースおよびテーブルは ndb_restore によって除外され、リストアされません。

次のテーブルに、--include-* オプションを使用した ndb_restore のいくつかの呼び出し (わかりやすくするためにほかのオプションが省略されている可能性があります) と、NDB Cluster バックアップからの復元に対するそれらの影響を示します:

これらの 2 つのオプションは一緒に使用することもできます。 たとえば、次の場合は、データベース db1 および db2 内のすべてのテーブルに加えて、データベース db3 内のテーブル t1 および t2 がリストアされます (ほかのデータベースまたはテーブルはリストアされません)。

shell> ndb_restore [...] --include-databases=db1,db2 --include-tables=db3.t1,db3.t2

(この例でも、必要となる可能性があるほかのオプションを省略しています。)

次に示す構文を使用して、--include-* (または --exclude-*) オプションなしで、選択したデータベースまたは選択したテーブルのみを単一のデータベースからリストアすることもできます:

ndb_restore other_options db_name,[db_name[,...] | tbl_name[,tbl_name][,...]]

言い換えると、次のいずれかをリストアすることを指定できます。

--lines-terminated-by=char

出力の各行を終了するために使用する文字列を指定します。 デフォルトは改行文字 (\n) です。

--lossy-conversions, -L

このオプションは、--promote-attributes オプションを補完することを意図しています。 --lossy-conversions を使用するときは、バックアップからデータをリストアするときにカラム値の不可逆変換 (型降格または符号の変更) が許可されます。 いくつかの例外はありますが、降格を制御するルールは MySQL レプリケーションの場合と同じです。属性降格によって現在サポートされる型変換については、セクション17.5.1.9.2「データ型が異なるカラムのレプリケーション」を参照してください。

ndb_restore は、不可逆変換中に実行されるデータの切り捨てを属性およびカラムごとに報告します。

--no-binlog

このオプションは、接続されている SQL ノードが ndb_restore によってリストアされるデータをバイナリログに書き込むことを阻止します。

--no-restore-disk-objects, -d

このオプションは、ndb_restore による NDB Cluster ディスクデータオブジェクト (テーブルスペースやログファイルグループなど) の復元を停止します。これらの詳細は、セクション23.5.10「NDB Cluster ディスクデータテーブル」 を参照してください。

--no-upgrade, -u

ndb_restore を使用してバックアップをリストアする場合、古い固定長形式を使用して作成された VARCHAR カラムは、現在採用されている可変幅形式を使用してサイズ変更および再作成されます。 この動作は、--no-upgrade を指定することでオーバーライドできます。

--ndb-nodegroup-map=map, -z

このオプションは、あるノードグループから取得されたバックアップを別のノードグループにリストアするために使用できます。 引数は、source_node_group, target_node_group という形式のリストです。

--nodeid=#, -n

バックアップが作成されたデータノードのノード ID を指定します。

バックアップが作成されたものとは異なる数のデータノードを持つクラスタにリストアする場合、この情報は、特定のノードにリストアされるファイルの正しいセットを識別するのに役立ちます。 (このような場合、通常は複数のファイルを単一のデータノードに復元する必要があります。) 追加情報および例については、セクション23.4.23.2「異なる数のデータノードへの復元」を参照してください。

NDB 8.0.15 以降では、このオプションは必須です。

--num-slices=#

スライスごとにバックアップを復元する場合、このオプションはバックアップを分割するスライスの数を設定します。 これにより、ndb_restore の複数のインスタンスで非結合サブセットをパラレルにリストアできるため、リストア操作の実行に必要な時間が短縮される可能性があります。

スライスは、特定のバックアップ内のデータのサブセットです。つまり、--slice-id オプションを使用して指定された同じスライス ID を持つフラグメントのセットです。 2 つのオプションは常に一緒に使用する必要があり、--slice-id によって設定される値は常にスライスの数より小さくする必要があります。

ndb_restore はフラグメントを検出し、各フラグメントにフラグメントカウンタを割り当てます。 スライスごとに復元する場合、スライス ID は各フラグメントに割り当てられます。このスライス ID は、スライスの数より 0 から 1 の範囲内にあります。 BLOB テーブルではないテーブルの場合、特定のフラグメントが属するスライスは、次に示す式を使用して決定されます:

[slice_ID] = [fragment_counter] % [number_of_slices]

BLOB テーブルの場合、フラグメントカウンタは使用されず、かわりにフラグメント番号が BLOB テーブルのメインテーブルの ID とともに使用されます (NDB では BLOB 値が内部的に別のテーブルに格納されることに注意してください)。 この場合、特定のフラグメントのスライス ID は次のように計算されます:

[slice_ID] =
([main_table_ID] + [fragment_ID]) % [number_of_slices]

したがって、N スライスによるリストアとは、ndb_restore の N インスタンスを実行し、すべて --num-slices= N (およびその他の必要なオプション) を使用し、それぞれに --slice-id=1, --slice-id=2, --slice-id=3 を使用して slice-id= N-1 を介して実行することです。

例.  各データノードのノードファイルシステム上のデフォルトディレクトリ/var/lib/mysql-cluster/BACKUP/BACKUP-3 にある BACKUP-1 という名前のバックアップを、ノード ID 1、2、3、および 4 を持つ 4 つのデータノードを持つクラスタに復元するとします。 5 つのスライスを使用してこの操作を実行するには、次のリストに示す一連のコマンドを実行します:

スライスは、クラスタデータのリストアにのみ使用する必要があります。メタデータ、インデックスまたはエポック情報のリストア時に --num-slices または --slice-id を使用する必要はありません。 これらの復元を制御する ndb_restore オプションとともにこれらのオプションの一方または両方が使用されている場合、プログラムはそれらを無視します。

--parallelism オプションを使用したリストア速度への影響は、ndb_restore の複数のインスタンスを使用したスライスまたはパラレルリストアによって生成されるものとは無関係です (--parallelism は single ndb_restore スレッドによって実行されるパラレルトランザクションの数を指定します)。ただし、これらのいずれかまたは両方とともに使用できます。 --parallelism を増やすと、ndb_restore のクラスタに大きな負荷がかかることに注意してください。システムでこれを処理できる場合は、リストアをさらに迅速に完了する必要があります。

--num-slices の値は、CPU または CPU コアの数、RAM の量などのハードウェアに関連する値に直接依存することはなく、LDM の数にも依存しません。

同じリストアの一部として、異なるデータノードでこのオプションに異なる値を使用することもできます。そうしないと、それ自体で悪影響が生じることはありません。

--parallelism=#, -p

ndb_restore では、単一行トランザクションを使用して多数の行を同時に適用します。 このパラメータは、ndb_restore のインスタンスが使用しようとするパラレルトランザクション (同時行) の数を決定します。 デフォルトでは、これは 128 であり、最小値は 1、最大値は 1024 です。

挿入を実行する作業は、関係するデータノード内のスレッド間で並列化されます。 このメカニズムは、.Data ファイル (データのファジースナップショット) からバルクデータをリストアするために使用されます。インデックスの作成または再構築には使用されません。 変更ログはシリアルに適用されます。インデックスの削除および構築は DDL 操作であり、個別に処理されます。 リストアのクライアント側にスレッドレベルの並列性はありません。

--preserve-trailing-spaces, -P

固定幅文字データ型を同等の可変幅に昇格させるとき、つまり CHAR カラム値を VARCHAR に昇格させるとき、または BINARY カラム値を VARBINARY に昇格させるときに、末尾の空白が保持されるようにします。 それ以外の場合は、新しいカラムに挿入されるときに、末尾の空白はそのようなカラム値から削除されます。

--print

ndb_restore がすべてのデータ、メタデータ、およびログを stdout に出力します。 --print-data、--print-meta および --print-log オプションを一緒に使用することと同等です。

--print-data

ndb_restore がその出力を stdout に送信するようにします。 多くの場合、1 つ以上の --tab, --fields-enclosed-by, --fields-optionally-enclosed-by, --fields-terminated-by, --hex および --append とともに使用されます。

TEXT および BLOB カラム値は常に切り捨てられます。 このような値は、出力の最初の 256 バイトに切り捨てられます。 現在、--print-data を使用している場合はオーバーライドできません。

--print-log

ndb_restore がログを stdout に出力するようにします。

--print-meta

すべてのメタデータを stdout に出力します。

print-sql-log

SQL ステートメントを stdout に記録します。 オプションを使用して有効にします。通常、この動作は無効になっています。 このオプションは、リストアされるすべてのテーブルに主キーが明示的に定義されているかどうかをログに記録する前にチェックします。NDB によって実装された非表示の主キーのみを持つテーブルに対するクエリーは、有効な SQL に変換できません。

このオプションは、BLOB カラムを含むテーブルでは機能しません。

--progress-frequency=N

バックアップの進行中に、ステータスレポートを N 秒ごとに出力します。0 (デフォルト) を指定すると、ステータスレポートは出力されません。 最大値は 65535 です。

--promote-attributes, -A

ndb_restore では、MySQL レプリケーションでサポートされているのとほぼ同じ方法で限定された属性プロモーションがサポートされます。つまり、特定のタイプのカラムからバックアップされたデータは、通常、「「大規模、類似」」タイプを使用してカラムにリストアできます。 たとえば、CHAR(20) カラムのデータは VARCHAR(20)、VARCHAR(30)、または CHAR(30) として宣言されているカラムにリストアでき、MEDIUMINT カラムのデータは、INT または BIGINT 型のカラムにリストアできます。 属性昇格によって現在サポートされる型変換の表については、セクション17.5.1.9.2「データ型が異なるカラムのレプリケーション」を参照してください。

ndb_restore による属性昇格は、次のように明示的に有効にする必要があります。

文字データ型と TEXT または BLOB の間で変換する場合は、文字型 (CHAR および VARCHAR) とバイナリ型 (BINARY および VARBINARY) の間の変換のみを同時に実行できます。 たとえば、同じ ndb_restore 呼び出しで、VARCHAR カラムを TEXT に昇格するときに、INT カラムを BIGINT に昇格できません。

異なる文字セットを使用した TEXT カラム間の変換はサポートされておらず、明示的には許可されません。

ndb_restore を使用して文字型またはバイナリ型から TEXT または BLOB への変換を実行するときに、table_name$STnode_id という名前の 1 つ以上のステージングテーブルが作成および使用されることに気付くことがあります。 これらのテーブルはその後必要ではなくなるため、通常はリストアが成功したあとに ndb_restore によって削除されます。

--rebuild-indexes

ネイティブ NDB バックアップのリストア中に、順序付けられたインデックスのマルチスレッド再構築を有効にします。 このオプションを使用して ndb_restore によって順序付けられたインデックスを構築するために使用されるスレッドの数は、BuildIndexThreads データノード構成パラメータと LDM の数によって制御されます。

このオプションを使用する必要があるのは、ndb_restore の最初の実行の場合のみです。これにより、以降のノードをリストアするときに --rebuild-indexes をふたたび使用しなくても、すべての順序付けられたインデックスが再構築されます。 このオプションはデータベースに新しい行を挿入する前に使用してください。そうしないと、インデックスを再構築しようとするときに、挿入される行があとで一意制約違反になることがあります。

順序付けされたインデックスの構築は、デフォルトで LDM の数で並列化されます。 ノードおよびシステムの再起動中に実行されるオフラインインデックス構築は、BuildIndexThreads データノード構成パラメータを使用して高速化できます。このパラメータは、オンラインで実行される ndb_restore によるインデックスの削除および再構築には影響しません。

一意インデックスの再構築では、Redo ロギングおよびローカルチェックポイント処理のディスク書き込み帯域幅が使用されます。 この帯域幅が十分ではない場合、Redo バッファーオーバーロードエラーまたはログオーバーロードエラーになることがあります。 そのような場合は、ndb_restore --rebuild-indexes を再度実行できます。この処理はエラーが発生した箇所から再開されます。 これは、一時エラーが発生した場合にも実行できます。 ndb_restore --rebuild-indexes の実行は無期限に繰り返すことができます。このようなエラーは、--parallelism の値を減らすことで停止できる場合があります。 領域不足の場合は、redo ログのサイズ (FragmentLogFileSize ノード構成パラメータ) を増やすか、LCP の実行速度 (MaxDiskWriteSpeed および関連パラメータ) を上げて領域をより迅速に解放できます。

--remap-column=db.tbl.col:fn:args

このオプションを --restore-data とともに使用すると、示されたカラムの値に関数が適用されます。 引数文字列の値を次に示します:

このオプションは、NDB ネイティブバックアップ (セクション23.5.8.2「NDB Cluster 管理クライアントを使用したバックアップの作成」 を参照) と ndb_restore を使用してデータをマージし、主キーと一意キーの値がソースクラスタ間で重複しており、これらの値を重複しない範囲に再マップするプロセスの一環として、NDB Cluster の複数のソースインスタンスに格納されているデータを単一の宛先 NDB Cluster にマージする場合に役立ちます。 テーブル間の他の関係を保持する必要がある場合もあります。 このような要件を満たすために、次に示すように、ndb_restore の同じ起動でオプションを複数回使用して、異なるテーブルのカラムを再マップできます:

shell> ndb_restore --restore-data --remap-column=hr.employee.id:offset:1000 \
    --remap-column=hr.manager.id:offset:1000 --remap-column=hr.firstaiders.id:offset:1000

(ここに示されていない他のオプションも使用できます。)

--remap-column を使用して、同じテーブルの複数のカラムを更新することもできます。 複数のテーブルとカラムの組合せが可能です。 次のように、同じテーブルの異なるカラムに異なるオフセット値を使用することもできます:

shell> ndb_restore --restore-data --remap-column=hr.employee.salary:offset:10000 \
    --remap-column=hr.employee.hours:offset:-10

マージしない重複テーブルがソースバックアップに含まれている場合は、--exclude-tables、--exclude-databases またはアプリケーション内の他の方法を使用してこれを処理できます。

マージされるテーブルの構造およびその他の特性に関する情報は、SHOW CREATE TABLE、ndb_desc ツール、MAX(), MIN(), LAST_INSERT_ID() およびその他の MySQL 関数を使用して取得できます。

NDB Cluster の個別のインスタンスで、マージされたテーブルからマージされていないテーブル、またはマージされていないテーブルからマージされたテーブルへの変更のレプリケーションはサポートされていません。

--restore-data, -r

NDB テーブルのデータおよびログを出力します。

--restore-epoch, -e

エポック情報をクラスタレプリケーションステータステーブルに追加 (またはリストア) します。 これは NDB Cluster レプリカでレプリケーションを開始する場合に役立ちます。 このオプションを使用すると、id カラムが 0 である mysql.ndb_apply_status 内の行が更新されます (存在する場合)。存在しない場合はそのような行が挿入されます (セクション23.6.9「NDB Cluster レプリケーションによる NDB Cluster バックアップ」を参照してください。)

--restore-meta, -m

このオプションを指定すると、ndb_restore が NDB テーブルメタデータを出力します。

ndb_restore リストアプログラムを最初に実行するときは、メタデータもリストアする必要があります。 つまり、データベーステーブルを再作成する必要があります。これは、--restore-meta (-m) オプションを指定して実行することで実行できます。 メタデータのリストアは、単一のデータノードでのみ実行する必要があります。これは、クラスタ全体にリストアするのに十分です。

古いバージョンの NDB Cluster では、このオプションを使用してスキーマが復元されたテーブルは、新しいクラスタとは異なる数のデータノードがあった場合でも、元のクラスタと同じ数のパーティションを使用していました。 NDB 8.0 では、メタデータを復元するときにこれは問題ではなくなりました。ローカルデータマネージャースレッドの数も元のクラスタ内のデータノードの数から変更されないかぎり、ndb_restore はターゲットクラスタのデフォルトのパーティション数を使用するようになりました。

NDB 8.0.16 以降でこのオプションを使用する場合は、ndb_restore がメタデータの復元を完了するまで ndb_metadata_check=OFF を設定して自動同期を無効にすることをお勧めします。その後、NDB ディクショナリに新しく作成されたオブジェクトを同期するために再度有効にすることができます。

--restore-privilege-tables

ndb_restore は、NDB 7.6 以前で実装されている分散特権をサポートしていない、バージョン 8.0 より前の NDB Cluster のリリースで作成された分散 MySQL 特権テーブルをデフォルトで復元しません。 このオプションを選択すると、ndb_restore によってリストアされます。

NDB 8.0.16 以降では、このようなテーブルはアクセス制御に使用されません。MySQL サーバーのアップグレードプロセスの一環として、サーバーはこれらのテーブルの InnoDB コピーをそれ自体に対してローカルに作成します。 詳細は、セクション23.2.7「NDB Cluster のアップグレードおよびダウングレード」 および セクション6.2.3「付与テーブル」 を参照してください。

--rewrite-database=olddb,newdb

このオプションを指定すると、バックアップに使用された名前と異なる名前を持つデータベースにリストアできます。 たとえば、バックアップが products という名前のデータベースから作成された場合は、このオプションを次のように使用して (必要となる可能性があるほかのオプションを省略しています)、含まれているデータを inventory という名前のデータベースにリストアできます。

shell> ndb_restore --rewrite-database=product,inventory

このオプションは、ndb_restore の単一呼び出しで複数回指定できます。 このため、--rewrite-database=db1,db2 --rewrite-database=db3,db4 を使用して、db1 という名前のデータベースから db2 という名前のデータベースに、および db3 という名前のデータベースから db4 という名前のデータベースに同時にリストアできます。 複数の --rewrite-database 発生箇所の間にほかの ndb_restore オプションを指定できます。

複数の --rewrite-database オプションで競合が発生した場合は、左から右に読んで最後に使用されている --rewrite-database オプションが有効となります。 たとえば、--rewrite-database=db1,db2 --rewrite-database=db1,db3 が使用された場合、--rewrite-database=db1,db3 のみが有効となり、--rewrite-database=db1,db2 は無視されます。 複数のデータベースから単一データベースにリストアすることもできるため、--rewrite-database=db1,db3 --rewrite-database=db2,db3 を指定すると、データベース db1 および db2 のすべてのテーブルおよびデータがデータベース db3 にリストアされます。

--skip-broken-objects

このオプションを指定すると、ndb_restore がネイティブ NDB バックアップを読み取るときに破損しているテーブルを無視して、残りのテーブル (破損していない) のリストアを続行します。 現在のところ、--skip-broken-objects オプションは BLOB パーツテーブルが欠けている場合にのみ機能します。

--skip-table-check, -s

テーブルメタデータをリストアせずにデータをリストアできます。 デフォルトでは、テーブルデータとテーブルスキーマの間に不一致が見つかった場合、ndb_restore はエラーで失敗します。このオプションはその動作をオーバーライドします。

ndb_restore を使用してデータをリストアするときのカラム定義内の不一致に関する制限の一部が緩和されています。それらのタイプの不一致のいずれかが発生しても、ndb_restore は以前のようにエラーで停止しなくなり、代わりにデータを受け入れてターゲットテーブルに挿入し、これが行われているという警告をユーザーに発行します。 この動作は、--skip-table-check オプションまたは --promote-attributes オプションが使用されているかどうかにかかわらず、実行されます。 カラム定義でのこれらの違いには次のタイプがあります。

--skip-unknown-objects

このオプションを指定すると、ndb_restore がネイティブ NDB バックアップを読み取るときに、認識されないスキーマオブジェクトを無視します。 これは、NDB 7.6 を実行しているクラスタから NDB Cluster 7.5 を実行しているクラスタに作成されたバックアップを復元するために使用できます。

--slice-id=#

スライスで復元する場合、これは復元するスライスの ID です。 このオプションは常に --num-slices とともに使用され、その値は常に --num-slices の値より小さくする必要があります。

詳細は、このセクションの他の場所にある --num-slices の説明を参照してください。

--tab=dir_name, -T dir_name

--print-data がダンプファイルをテーブルごとに作成し、それぞれに tbl_name.txt という名前を付けます。 ファイルを保存すべきディレクトリへのパスを引数が必要です。現在のディレクトリの場合は . を使用します。

--verbose=#

出力の冗長性のレベルを設定します。 最小値は 0 であり、最大値は 255 です。 デフォルト値は 1 です。