PDF (US Ltr)
- 26.8Mb
PDF (A4)
- 26.8Mb
HTML Download (TGZ)
- 7.2Mb
HTML Download (Zip)
- 7.2Mb
クラスタリストアプログラムは、別個のコマンド行ユーティリティー ndb_restore として実装されており、通常は MySQL の bin ディレクトリにあります。このプログラムは、バックアップの結果として作成されたファイルを読み取り、格納されている情報をデータベースに挿入します。
ndb_restore は、バックアップを作成するために使用される START BACKUP コマンド (セクション18.5.3.2「MySQL Cluster 管理クライアントを使用したバックアップの作成」を参照してください) によって作成されたバックアップファイルごとに、一度実行する必要があります。これは、バックアップが作成された時点の、クラスタ内のデータノード数と同じです。
注記
複数のデータノードを並列でリストアしている場合を除き、ndb_restore を使用する前に、クラスタをシングルユーザーモードで実行することをお勧めします。詳細は、セクション18.5.8「MySQL Cluster のシングルユーザーモード」を参照してください。
次の表には、MySQL Cluster ネイティブバックアップリストアプログラム ndb_restore に固有のオプションが含まれています。追加説明が表のあとにあります。ほとんどの MySQL Cluster プログラム (ndb_restore を含む) に共通するオプションについては、セクション18.4.27「MySQL Cluster プログラムに共通するオプション — MySQL Cluster プログラムに共通するオプション」を参照してください。
表 18.90 この表は、ndb_restore プログラムのコマンド行オプションについて説明しています
| 形式 | 説明 | 追加または削除 |
|---|---|---|
| --connectstring のエイリアス。 |
すべての MySQL 5.6 ベースリリース |
|
| この ID のノードからファイルをバックアップします |
すべての MySQL 5.6 ベースリリース |
|
| 指定された ID のバックアップからリストアします |
すべての MySQL 5.6 ベースリリース |
|
| NDB API を使用してテーブルデータおよびログを NDB Cluster にリストアします |
すべての MySQL 5.6 ベースリリース |
|
| NDB API を使用してメタデータを NDB Cluster にリストアします |
すべての MySQL 5.6 ベースリリース |
|
| VAR データがまだサイズ変更されていない可変サイズ属性の配列タイプをアップグレードせず、カラム属性を変更しません |
すべての MySQL 5.6 ベースリリース |
|
| バックアップからデータをリストアするときに、属性の昇格を許可します |
すべての MySQL 5.6 ベースリリース |
|
| 固定幅文字列型を可変幅型に昇格するときに、末尾の空白 (パディングを含む) を維持することを許可します |
すべての MySQL 5.6 ベースリリース |
|
| ディスクデータに関連するオブジェクトをリストアしません |
すべての MySQL 5.6 ベースリリース |
|
| エポック情報をステータステーブルにリストアします。MySQL Cluster レプリケーションスレーブでレプリケーションを開始する場合に便利です。mysql.ndb_apply_status の ID 0 の行が更新/挿入されます。 |
すべての MySQL 5.6 ベースリリース |
|
| データのリストア中に、テーブル構造チェックをスキップします |
すべての MySQL 5.6 ベースリリース |
|
| データのリストア中に使用する並列トランザクションの数 |
すべての MySQL 5.6 ベースリリース |
|
| メタデータ、データ、およびログを stdout に出力します (--print_meta --print_data --print_log と同等です) |
すべての MySQL 5.6 ベースリリース |
|
| メタデータを stdout に出力します |
すべての MySQL 5.6 ベースリリース |
|
| データを stdout に出力します |
すべての MySQL 5.6 ベースリリース |
|
| stdout に出力します |
すべての MySQL 5.6 ベースリリース |
|
| バックアップファイルディレクトリへのパス |
すべての MySQL 5.6 ベースリリース |
|
| リストア中にシステムテーブルを無視しません。実験用であり、本番で使用するためのものではありません |
すべての MySQL 5.6 ベースリリース |
|
| NDBCLUSTER ストレージエンジンのためのノードグループマップ。構文: (source_nodegroup, destination_nodegroup) のリスト |
すべての MySQL 5.6 ベースリリース |
|
| フィールドが指定された文字で囲まれます |
すべての MySQL 5.6 ベースリリース |
|
| フィールドが指定された文字で終了します |
すべての MySQL 5.6 ベースリリース |
|
| フィールドは、必要に応じて指定された文字で囲まれます |
すべての MySQL 5.6 ベースリリース |
|
| 指定された文字で行が終了します |
すべての MySQL 5.6 ベースリリース |
|
| バイナリタイプを 16 進形式で出力します |
すべての MySQL 5.6 ベースリリース |
|
| 指定されたパス内の各テーブルの、タブ区切りの .txt ファイルを作成します |
すべての MySQL 5.6 ベースリリース |
|
| タブ区切りのファイルにデータを追加します |
すべての MySQL 5.6 ベースリリース |
|
| 指定された秒数おきに、リストアのステータスを出力します |
すべての MySQL 5.6 ベースリリース |
|
| mysqld が接続されていて、バイナリロギングを使用している場合、リストアされたデータのログを記録しません |
すべての MySQL 5.6 ベースリリース |
|
| 出力の冗長性レベル |
すべての MySQL 5.6 ベースリリース |
|
| 1 つ以上のリストアするデータベースのリスト (指定されていないものを除外します) |
すべての MySQL 5.6 ベースリリース |
|
| 1 つ以上の除外するデータベースのリスト (指定されていないものを含めます) |
すべての MySQL 5.6 ベースリリース |
|
| リストアする 1 つ以上のテーブルのリスト (同じデータベース内の指定されていないものを除外します)。各テーブル参照にはデータベース名が含まれている必要があります |
すべての MySQL 5.6 ベースリリース |
|
| 除外する 1 つ以上のテーブルのリスト (同じデータベース内の指定されていないものを含めます)。各テーブル参照にはデータベース名が含まれている必要があります |
すべての MySQL 5.6 ベースリリース |
|
| バックアップバージョンのテーブルから、データベース内のバージョンのテーブルにないカラムが無視されます。 |
すべての MySQL 5.6 ベースリリース |
|
| バックアップから、データベースにないテーブルが無視されます。 |
追加: NDB 7.3.7 |
|
| バックアップ内のインデックスが無視されます。データのリストアに必要となる時間が短くなることがあります。 |
すべての MySQL 5.6 ベースリリース |
|
| バックアップで見つかった順序付けされたインデックスをマルチスレッドで再構築します。使用されるスレッド数は、BuildIndexThreads パラメータを設定することによって決定されます。 |
すべての MySQL 5.6 ベースリリース |
|
| バックアップファイル内で欠けている BLOB テーブルが無視されます。 |
すべての MySQL 5.6 ベースリリース |
|
| 新しいバージョンの MySQL Cluster から作成されたバックアップを古いバージョンにリストアするときに、ndb_restore によって認識されないスキーマオブジェクトが無視されます。 |
すべての MySQL 5.6 ベースリリース |
|
| 元の名前と異なる名前のデータベースにリストアします |
すべての MySQL 5.6 ベースリリース |
|
| バックアップからデータをリストアするときに、カラム値の不可逆変換 (型の昇格または符号の変更) を許可します |
すべての MySQL 5.6 ベースリリース |
|
| 以前 NDB に移動された MySQL 権限テーブルをリストアします。 |
すべての MySQL 5.6 ベースリリース |
|
| TRUE (デフォルト) の場合は、ALTER TABLE のコピー操作で残された中間テーブル (名前の前に「#sql-」が付けられています) がリストアされません。 |
追加: NDB 7.3.6 |
このユーティリティーの一般的なオプションを次に示します。
通常、MySQL Cluster のバックアップからリストアする場合、ndb_restore では --nodeid (短縮形: -n)、--backupid (短縮形: -b)、および --backup_path オプションが最低限必要となります。
ndb_restore [-c connection_string] -n node_id -b backup_id \
[-m] -r --backup_path=/path/to/backup/files
-c オプションは、ndb_restore にクラスタ管理サーバーを探す場所を伝える接続文字列を指定するために使用します。(接続文字列については、セクション18.3.2.3「MySQL Cluster の接続文字列」を参照してください)。このオプションを使用しない場合、ndb_restore は localhost:1186 の管理サーバーに接続を試みます。このユーティリティーはクラスタ API ノードとして動作するため、クラスタ管理サーバーに接続するための空き接続「スロット」が必要となります。これは、クラスタ config.ini ファイル内にそれが使用できる [api] セクションまたは [mysqld] セクションが少なくとも 1 つ存在する必要があることを意味します。このため、MySQL サーバーまたはほかのアプリケーションに使用されていない空の [api] セクションまたは [mysqld] セクションを、config.ini 内に少なくとも 1 つ用意することをお勧めします (セクション18.3.2.7「MySQL Cluster 内の SQL ノードおよびその他の API ノードの定義」を参照してください)。
ndb_restore がクラスタに接続されていることを確認するには、ndb_mgm 管理クライアントで SHOW コマンドを使用します。システムシェルで次のようにすることでこれを実現することもできます。
shell> ndb_mgm -e "SHOW"
-n はバックアップが取得されたデータノードのノード ID を指定するために使用します。
ndb_restore リストアプログラムを最初に実行するときは、メタデータもリストアする必要があります。言い換えると、データベーステーブルを再作成する必要があります。これは、--restore_meta (-m) オプションを指定して実行することによって行うことができます。メタデータをリストアする必要があるのは単一データノードだけです。これで十分にクラスタ全体にリストアできます。バックアップのリストアを開始するときには、クラスタに空のデータベースがあるべきでます(言い換えると、リストアを実行する前に、--initial を指定して ndbd を開始してください)。
テーブルメタデータをリストアしなくてもデータをリストアできます。これを行うときのデフォルト動作は、テーブルデータがテーブルスキーマと一致しない場合に ndb_restore がエラーで失敗することです。これは、--skip-table-check オプションまたは -s オプションを使用してオーバーライドできます。
ndb_restore を使用してデータをリストアするときのカラム定義内の不一致に関する制限の一部が緩和されています。それらのタイプの不一致のいずれかが発生しても、ndb_restore は以前のようにエラーで停止しなくなり、代わりにデータを受け入れてターゲットテーブルに挿入し、これが行われているという警告をユーザーに発行します。この動作は、--skip-table-check オプションまたは --promote-attributes オプションが使用されているかどうかにかかわらず、実行されます。カラム定義でのこれらの違いには次のタイプがあります。
異なる
COLUMN_FORMAT設定 (FIXED、DYNAMIC、DEFAULT)異なる
STORAGE設定 (MEMORY、DISK)異なるデフォルト値
異なる配布キー設定
ndb_restore は、MySQL レプリケーションでサポートされるのとほぼ同様に、属性昇格を制限付きでサポートします。つまり、特定の型のカラムからバックアップされたデータは一般的に、「より大きい同様の」型を使用してカラムにリストアできます。たとえば、CHAR(20) カラムのデータは VARCHAR(20)、VARCHAR(30)、または CHAR(30) として宣言されているカラムにリストアでき、MEDIUMINT カラムのデータは、INT または BIGINT 型のカラムにリストアできます。属性昇格によって現在サポートされる型変換の表については、セクション17.4.1.9.2「データ型が異なるカラムのレプリケーション」を参照してください。
ndb_restore による属性昇格は、次のように明示的に有効にする必要があります。
バックアップをリストアするテーブルを準備します。ndb_restore を使用してオリジナルと異なる定義でテーブルを再作成することはできません。これは、テーブルを手動で作成するか、またはテーブルメタデータをリストアしたあとかつデータをリストアする前に昇格するカラムを
ALTER TABLEを使用して変更する必要があることを意味します。テーブルデータをリストアするときに、
--promote-attributesオプション (短縮形:-A) を指定してndb_restore を呼び出します。このオプションを使用しない場合、属性昇格は行われず、リストア操作がエラーで失敗します。
MySQL Cluster NDB 7.3.3 より前は、文字データ型と TEXT または BLOB の間の変換が正しく処理されませんでした (Bug #17325051)。
MySQL Cluster NDB 7.3.7 より前は、TEXT から TINYTEXT への降格が正しく処理されませんでした (Bug #18875137)。
文字データ型と TEXT または BLOB の間で変換する場合は、文字型 (CHAR および VARCHAR) とバイナリ型 (BINARY および VARBINARY) の間の変換のみを同時に実行できます。たとえば、同じ ndb_restore 呼び出しで、VARCHAR カラムを TEXT に昇格するときに、INT カラムを BIGINT に昇格できません。
異なる文字セットが使用されている TEXT カラム間の変換はサポートされていません。MySQL Cluster NDB 7.3.7 以降では、これは明確に許可されません (Bug #18875137)。
ndb_restore を使用して文字型またはバイナリ型から TEXT または BLOB への変換を実行するときに、table_name$STnode_id
| コマンド行形式 | --lossy-conversions |
|---|---|
| 型 | ブール |
| デフォルト |
FALSE (オプションを使用しない場合) |
このオプションは、--promote-attributes オプションを補完することを意図しています。--lossy-conversions を使用するときは、バックアップからデータをリストアするときにカラム値の不可逆変換 (型降格または符号の変更) が許可されます。いくつかの例外はありますが、降格を制御するルールは MySQL レプリケーションの場合と同じです。属性降格によって現在サポートされる型変換については、セクション17.4.1.9.2「データ型が異なるカラムのレプリケーション」を参照してください。
ndb_restore は、不可逆変換中に実行されるデータの切り捨てを属性およびカラムごとに報告します。
--preserve-trailing-spaces オプション (短縮形: -R) を使用すると、固定幅の文字データ型を可変幅の同等の型に昇格するとき (つまり、CHAR カラム値を VARCHAR に、または BINARY カラム値を VARBINARY に昇格するとき) に、末尾の空白が維持されます。それ以外の場合は、新しいカラムに挿入されるときに、末尾の空白はそのようなカラム値から削除されます。
注記
CHAR カラムを VARCHAR に、および BINARY カラムを VARBINARY に昇格することはできますが、VARCHAR カラムを CHAR に、または VARBINARY カラムを BINARY に昇格することはできません。
-b オプションはバックアップの ID またはシーケンス番号を指定するために使用し、バックアップ完了時に表示される「Backup メッセージで管理クライアントによって示される番号と同じ番号です。(セクション18.5.3.2「MySQL Cluster 管理クライアントを使用したバックアップの作成」を参照してください)。
backup_id completed」
重要
クラスタバックアップをリストアするときは、同じバックアップ ID を持つバックアップからすべてのデータノードをリストアする必要があります。別のバックアップのファイルを使用すると、クラスタがリストアされたとしても不整合性な状態で、要するに失敗する可能性があります。
--restore_epoch (短縮形: -e) は、エポック情報をクラスタレプリケーションステータステーブルに追加 (またはリストア) します。これは、MySQL Cluster レプリケーションスレーブでレプリケーションを開始する場合に便利です。このオプションを使用すると、id カラムが 0 である mysql.ndb_apply_status 内の行が更新されます (存在する場合)。存在しない場合はそのような行が挿入されます(セクション18.6.9「MySQL Cluster レプリケーションを使用した MySQL Cluster バックアップ」を参照してください)。
このオプションを指定すると、ndb_restore が NDB テーブルデータおよびログを出力します。
このオプションを指定すると、ndb_restore が NDB テーブルメタデータを出力します。通常、このオプションを使用する必要があるのは、クラスタの最初のデータノードをリストアする場合のみです。追加データノードは最初のものからメタデータを取得できます。
デフォルトでは、ndb_restore は配布された MySQL 権限テーブルをリストアしません。このオプションを指定すると、ndb_restore が権限テーブルをリストアします。
これが動作するのは、バックアップが取得される前に、権限テーブルが NDB に変換された場合のみです。詳細は、セクション18.5.14「MySQL Cluster の配布された MySQL 権限」を参照してください。
バックアップディレクトリへのパスが必要です。これは --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= を前に付けることができます。
作成されたデータベースとは異なる構成のデータベースにバックアップをリストアできます。たとえば、ノード ID 2 および 3 の 2 つのデータベースノードがあるクラスタで作成されたバックアップ ID 12 のバックアップを 4 ノードのクラスタに復旧するとします。その場合は、ndb_restore を 2 回実行する必要があります (バックアップを取得したクラスタのデータベースノードごとに 1 回)。ただし、ndb_restore はあるバージョンの MySQL で実行されているクラスタから作成されたバックアップを、別のバージョンの MySQL で実行されているクラスタに常に復旧できるとはかぎりません。詳細は、セクション18.2.8「MySQL Cluster NDB 7.3 のアップグレードとダウングレード」を参照してください。
重要
新しいバージョンの MySQL Cluster から作成したバックアップを古いバージョンの ndb_restore を使用してリストアすることはできません。新しいバージョンの MySQL から作成したバックアップを古いクラスタにリストアすることはできますが、それを行うには新しいバージョンの MySQL Cluster の ndb_restore のコピーを使用する必要があります。
たとえば、MySQL Cluster NDB 7.2.5 を実行しているクラスタから取得したクラスタバックアップを MySQL Cluster NDB 7.1.21 を実行しているクラスタにリストアするには、MySQL Cluster NDB 7.2.5 配布に付属する ndb_restore を使用する必要があります。
リストアをより高速にするために、十分な数のクラスタ接続が使用できる場合は、データを並列でリストアできます。より正確に言うと、複数のノードを並列でリストアする場合は、各並列 ndb_restore プロセスに使用できる [api] または [mysqld] セクションがクラスタ config.ini ファイルに存在する必要があります。ただし、データファイルは常にログの前に適用する必要があります。
ndb_restore を使用してバックアップをリストアする場合、古い固定長形式を使用して作成された VARCHAR カラムは、現在採用されている可変幅形式を使用してサイズ変更および再作成されます。この動作は、ndb_restore を実行するときに、--no-upgrade オプション (短縮形: -u) を使用してオーバーライドできます。
--print_data オプションを指定すると、ndb_restore が出力を stdout にリダイレクトします。
TEXT および BLOB カラム値は常に切り捨てられます。MySQL Cluster NDB 7.3.7 以前では、そのような値は出力で最初の 240 バイトに切り捨てられ、MySQL Cluster NDB 7.3.8 以降では、256 バイトに切り捨てられます(Bug #14571512、Bug #65467)。これは現在 --print_data を使用してもオーバーライドできません。
データダンプを stdout またはファイルに生成する際に、いくつかの追加オプションを --print_data オプションとともに使用できます。これらは mysqldump で使用される一部のオプションに似ており、次のリストに示されています。
-
コマンド行形式 --tab=pathこのオプションを使用すると、
--print_dataはテーブルごとに、それぞれtbl_name.txt.を使用します。 -
コマンド行形式 --fields-enclosed-by=char型 文字列 デフォルト 各カラム値は、このオプションに渡された文字列によって囲まれます (データ型は関係ありません。次の項目を参照してください)。
-
--fields-optionally-enclosed-by=stringコマンド行形式 --fields-optionally-enclosed-by型 文字列 デフォルト このオプションに渡された文字列は、文字データが含まれているカラム値 (
CHAR、VARCHAR、BINARY、TEXT、ENUMなど) を囲むために使用されます。 -
コマンド行形式 --fields-terminated-by=char型 文字列 デフォルト \t (tab)このオプションに渡された文字列は、カラム値を区切るために使用されます。デフォルト値はタブ文字 (
\t) です。 -
コマンド行形式 --hexこのオプションを使用すると、すべてのバイナリ値は 16 進形式で出力されます。
-
コマンド行形式 --fields-terminated-by=char型 文字列 デフォルト \t (tab)このオプションは、出力の各行を終了するために使用される文字列を指定します。デフォルトは改行文字 (
\n) です。 -
コマンド行形式 --append--tabオプションおよび--print_dataオプションとともに使用した場合、同じ名前を持つ既存のファイルにデータが付加されます。
注記
テーブルに明示的な主キーがない場合、--print_data オプションを使用して生成される出力には、テーブルの隠し主キーが含められます。
このオプションを指定すると、ndb_restore がすべてのメタデータをstdout に出力します。
--print_log オプションを指定すると、ndb_restore がログを stdout に出力します。
ndb_restore がすべてのデータ、メタデータ、およびログを stdout に出力します。--print_data、--print_meta、および --print_log オプションを一緒に使用することと同等です。
注記
--print または --print_* オプションのいずれかを使用した場合は、仮実行をするときに有効になります。これらのオプションを 1 つ以上含めると、出力が stdout にリダイレクトされます。そのような場合、ndb_restore はデータまたはメタデータを MySQL Cluster にリストアしようとしません。
通常、テーブルデータおよびメタデータをリストアするときに、ndb_restore はバックアップに存在する NDB システムテーブルのコピーを無視します。--dont_ignore_systab_0 を指定すると、システムテーブルがリストアされます。このオプションは、実験および開発での使用のみが意図されており、本番環境には推奨されていません。
このオプションは、あるノードグループから取得されたバックアップを別のノードグループにリストアするために使用できます。引数は、source_node_group, target_node_group
このオプションは、接続されている SQL ノードが ndb_restore によってリストアされるデータをバイナリログに書き込むことを阻止します。
このオプションを指定すると、ndb_restore が MySQL Cluster ディスクデータオブジェクト (テーブルスペース、ログファイルグループなど) をリストアすることを阻止します。これらの詳細は、セクション18.5.12「MySQL Cluster ディスクデータテーブル」を参照してください。
ndb_restore が使用を試みることができる並列トランザクションの最大数を決定します。デフォルトでは、これは 128 であり、最小値は 1、最大値は 1024 です。
バックアップの進行中に、ステータスレポートを N 秒ごとに出力します。0 (デフォルト) を指定すると、ステータスレポートは出力されません。最大値は 65535 です。
出力の冗長性のレベルを設定します。最小値は 0 であり、最大値は 255 です。デフォルト値は 1 です。
次に示す構文を使用すると、選択したデータベースのみ、または単一データベースの選択したテーブルのみをリストアできます。
ndb_restore other_options db_name,[db_name[,...] | tbl_name[,tbl_name][,...]]言い換えると、次のいずれかをリストアすることを指定できます。
1 つ以上のデータベースのすべてのテーブル
単一データベースの 1 つ以上のテーブル
--include-databases=
db_name[,db_name][,...]
| コマンド行形式 | --include-databases=db-list |
|---|---|
| 型 | 文字列 |
| デフォルト | |
--include-tables=
db_name.tbl_name[,db_name.tbl_name][,...]
| コマンド行形式 | --include-tables=table-list |
|---|---|
| 型 | 文字列 |
| デフォルト | |
特定のデータベースまたはテーブルのみをリストアするには、--include-databases オプションまたは --include-tables オプションをそれぞれ使用します。--include-databases は、リストアするデータベースのカンマ区切りリストを受け入れます。--include-tables はリストアするテーブルのカンマ区切りリスト (database.table
--include-databases または --include-tables を使用すると、それらのオプションによって指定されたデータベースまたはテーブルのみがリストアされます。ほかのすべてのデータベースおよびテーブルは ndb_restore によって除外され、リストアされません。
次の表は、--include-* オプション (必要となる可能性があるほかのオプションは、わかりやすくするために省略しています) を使用した ndb_restore のいくつかの呼び出し、および MySQL Cluster バックアップからリストアする場合のそれらの効果を示しています。
| 使用するオプション | 結果 |
|---|---|
--include-databases=db1 |
データベース db1 内のテーブルのみがリストアされます。ほかのすべてのデータベース内のすべてのテーブルは無視されます |
--include-databases=db1,db2 (または --include-databases=db1 --include-databases=db2) |
データベース db1 および db2 内のテーブルのみがリストアされます。ほかのすべてのデータベース内のすべてのテーブルは無視されます |
--include-tables=db1.t1 |
データベース db1 内のテーブル t1 のみがリストアされます。db1 またはその他のデータベース内のほかのテーブルはリストアされません |
--include-tables=db1.t2,db2.t1 (または --include-tables=db1.t2 --include-tables=db2.t1) |
データベース db1 内のテーブル t2 およびデータベース db2 内のテーブル t1 のみがリストアされます。db1、db2、またはその他のデータベース内のほかのテーブルはリストアされません |
これらの 2 つのオプションは一緒に使用することもできます。たとえば、次の場合は、データベース db1 および db2 内のすべてのテーブルに加えて、データベース db3 内のテーブル t1 および t2 がリストアされます (ほかのデータベースまたはテーブルはリストアされません)。
shell> ndb_restore [...] --include-databases=db1,db2 --include-tables=db3.t1,db3.t2(この例でも、必要となる可能性があるほかのオプションを省略しています。)
--exclude-databases=
db_name[,db_name][,...]
| コマンド行形式 | --exclude-databases=db-list |
|---|---|
| 型 | 文字列 |
| デフォルト | |
--exclude-tables=
db_name.tbl_name[,db_name.tbl_name][,...]
| コマンド行形式 | --exclude-tables=table-list |
|---|---|
| 型 | 文字列 |
| デフォルト | |
1 つ以上のデータベースまたはテーブルがリストアされないようにするには、ndb_restore の --exclude-databases および --exclude-tables オプションを使用します。--exclude-databases はリストアすべきでない 1 つ以上のデータベースのカンマ区切りリストを受け入れます。--exclude-tables はリストアすべきでない 1 つ以上のテーブルのカンマ区切りリスト (database.table
--exclude-databases または --exclude-tables を使用した場合は、これらのオプションによって指定されたデータベースまたはテーブルのみが除外されます。ほかのすべてのデータベースおよびテーブルは ndb_restore によってリストアされます。
次の表は、--exclude-* オプション (必要となる可能性があるほかのオプションは、わかりやすくするために省略しています) を使用したいくつかの ndb_restore 呼び出し、および MySQL Cluster バックアップからリストアする場合にこれらのオプションが持つ効果を示しています。
| 使用するオプション | 結果 |
|---|---|
--exclude-databases=db1 |
db1 を除くすべてのデータベース内のすべてのテーブルがリストアされます。db1 内のテーブルはリストアされません |
--exclude-databases=db1,db2 (または --exclude-databases=db1 --exclude-databases=db2) |
db1 および db2 を除くすべてのデータベース内のすべてのテーブルがリストアされます。db1 または db2 内のテーブルはリストアされません |
--exclude-tables=db1.t1 |
データベース db1 内の t1 を除くすべてのテーブルがリストアされます。db1 内のほかのすべてのテーブルはリストアされます。ほかのすべてのデータベース内のすべてのテーブルはリストアされます |
--exclude-tables=db1.t2,db2.t1 (または --exclude-tables=db1.t2 --exclude-tables=db2.t1)
|
データベース db1 内の t2 を除くすべてのテーブル、およびデータベース db2 内の t1 を除くすべてのテーブルがリストアされます。db1 または db2 内のほかのテーブルはリストアされません。ほかのすべてのデータベース内のすべてのテーブルはリストアされます |
これらの 2 つのオプションは一緒に使用できます。たとえば、次の場合は、データベース db1 と db2、およびデータベース db3 内のテーブル t1 と t2 を除くすべてのデータベース内のすべてのテーブルがリストアされません。
shell> ndb_restore [...] --exclude-databases=db1,db2 --exclude-tables=db3.t1,db3.t2(この例でも、わかりやすく簡潔にするために、必要となる可能性があるほかのオプションを省略しています)。
--include-* オプションおよび --exclude-* オプションは、次のルールに従って一緒に使用できます。
すべての
--include-*および--exclude-*オプションのアクションは累積されます。すべての
--include-*および--exclude-*オプションは、ndb_restore に渡された順序で右から左に評価されます。競合するオプションがある場合は、最初 (もっとも右側) のオプションが優先されます。言い換えると、対象となるデータベースまたはテーブルと一致する最初のオプション (右から左に適用して) が「適用されます」。
たとえば、次の一連のオプションを指定すると、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| コマンド行形式 | --exclude-missing-columns |
|---|
--exclude-missing-columns オプションを使用すると、選択したテーブルカラムのみをリストアすることもできます。このオプションを使用するときは、ndb_restore は、バックアップで見つかったテーブルのバージョンと比較して、リストアされるテーブルで欠けているカラムを無視します。このオプションはリストアされるすべてのテーブルに適用されます。選択したテーブルまたはデータベースのみにこのオプションを適用したい場合は、それを実行する際に前の段落で説明したオプションの 1 つ以上を組み合わせて使用できます。つまり、残りのテーブルには、それらのオプションセットを補完的に使用してデータをリストアできます。
| コマンド行形式 | --exclude-missing-tables |
|---|---|
| 導入 | 5.6.21-ndb-7.3.7 |
MySQL Cluster NDB 7.3.7 以降では、このオプションを使用して選択したテーブルカラムのみをリストアすることもでき、その場合、ndb_restore はバックアップからターゲットデータベースにないテーブルを無視します。
| コマンド行形式 | --disable-indexes |
|---|
ネイティブ NDB バックアップからのデータのリストア中に、インデックスのリストアを無効にします。あとで、--rebuild-indexes を使用してマルチスレッドでインデックスを構築することで、すべてのテーブルのインデックスを一度にリストアできます。非常に大きいテーブルの場合には、インデックスを同時に再構築するよりもこの方が速いはずです。
| コマンド行形式 | --rebuild-indexes |
|---|
ndb_restore でこのオプションを使用すると、ネイティブ NDB バックアップのリストア中に、順序付けされたインデックスがマルチスレッドで再構築されます。このオプション付きの ndb_restore で順序付けされたインデックスを構築するために使用されるスレッドの数は、BuildIndexThreads データノード構成パラメータによって制御されます。
このオプションを使用する必要があるのは、ndb_restore の最初の実行の場合のみです。これにより、以降のノードをリストアするときに --rebuild-indexes をふたたび使用しなくても、すべての順序付けられたインデックスが再構築されます。このオプションはデータベースに新しい行を挿入する前に使用してください。そうしないと、インデックスを再構築しようとするときに、挿入される行があとで一意制約違反になることがあります。
一意インデックスの再構築では、Redo ロギングおよびローカルチェックポイント処理のディスク書き込み帯域幅が使用されます。この帯域幅が十分ではない場合、Redo バッファーオーバーロードエラーまたはログオーバーロードエラーになることがあります。そのような場合は、ndb_restore --rebuild-indexes を再度実行できます。この処理はエラーが発生した箇所から再開されます。これは、一時エラーが発生したときにも行うことができます。ndb_restore --rebuild-indexes の実行は無限に繰り返すことができます。DiskCheckpointSpeed の値を減らして Redo ロギングに追加のディスク帯域幅を与えることによって、そのようなエラーを停止できることがあります。
| コマンド行形式 | --skip-broken-objects |
|---|
このオプションを指定すると、ndb_restore がネイティブ NDB バックアップを読み取るときに破損しているテーブルを無視して、残りのテーブル (破損していない) のリストアを続行します。現在のところ、--skip-broken-objects オプションは BLOB パーツテーブルが欠けている場合にのみ機能します。
| コマンド行形式 | --skip-unknown-objects |
|---|
このオプションを指定すると、ndb_restore がネイティブ NDB バックアップを読み取るときに、認識されないスキーマオブジェクトを無視します。これは、MySQL Cluster NDB 7.3 を実行しているクラスタから作成されたバックアップを MySQL Cluster NDB 7.2 を実行しているクラスタにリストアするために使用できます。
--rewrite-database=
old_dbname,new_dbname
| コマンド行形式 | --rewrite-database=olddb,newdb |
|---|---|
| 型 | 文字列 |
| デフォルト | none |
このオプションを指定すると、バックアップに使用された名前と異なる名前を持つデータベースにリストアできます。たとえば、バックアップが 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 にリストアされます。
重要
--rewrite-database を使用して複数のバックアップデータベースから単一ターゲットデータベースにリストアする場合、テーブル名またはその他のオブジェクト名間の競合はチェックされず、行がリストアされる順序は保証されません。これは、そのような場合に行が上書きされて更新が失われることがあることを意味します。
--exclude-intermediate-sql-tables[=TRUE|FALSE]
| コマンド行形式 | --exclude-intermediate-sql-tables[=TRUE|FALSE] |
|---|---|
| 導入 | 5.6.17-ndb-7.3.6 |
| 型 | ブール |
| デフォルト | TRUE |
ALTER TABLE のコピー操作を実行するときに、mysqld は中間テーブルを作成します (名前の前に #sql- が付けられます)。TRUE を指定すると、--exclude-intermediate-sql-tables オプションによって、ndb_restore がそのような操作で残された可能性があるテーブルをリストアしなくなります。このオプションはデフォルトでは TRUE です。
--exclude-intermediate-sql-tables オプションは MySQL Cluster NDB 7.3.6 で導入されました。(Bug #17882305)
エラー報告
ndb_restore は一時的および永続的エラーの両方を報告します。一時エラーの場合は、それらからリカバリできる場合があり、そのようなときには「Restore successful, but encountered temporary error, please look at configuration」と報告されます。
重要
ndb_restore を使用して循環レプリケーションに使用するために MySQL Cluster を初期化したあとに、レプリケーションスレーブとして動作する SQL ノード上のバイナリログは自動的に作成されないため、それらを作成させるように手動で操作する必要があります。バイナリログを作成させるには、START SLAVE を実行する前に、その SQL ノードで SHOW TABLES ステートメントを発行します。これは MySQL Cluster の既知の問題です。