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

23.4.23.2 異なる数のデータノードへの復元

23.4.23.2.1 元のノードより少ないノードへのリストア

23.4.23.2.2 元のノードより多くのノードへのリストア

NDB バックアップから、バックアップが作成された元のものとは異なる数のデータノードを持つクラスタに復元できます。 次の 2 つのセクションでは、ターゲットクラスタのデータノード数がバックアップのソースより少ないか多い場合についてそれぞれ説明します。

23.4.23.2.1 元のノードより少ないノードへのリストア

多数のノードが小さい数の偶数倍である場合は、元のノードより少ないデータノードを持つクラスタに復元できます。 次の例では、4 つのデータノードを持つクラスタで作成したバックアップを、2 つのデータノードを持つクラスタに使用します。

1. 元のクラスタの管理サーバーはホスト host10 上にあります。 元のクラスタには 4 つのデータノードがあり、ノード ID とホスト名は次のように管理サーバーの config.ini ファイルから抽出されたものです:

   [ndbd]
   NodeId=2
   HostName=host2
   
   [ndbd]
   NodeId=4
   HostName=host4
   
   [ndbd]
   NodeId=6
   HostName=host6
   
   [ndbd]
   NodeId=8
   HostName=host8

   各データノードは、最初は ndbmtd --ndb-connectstring=host10 または同等のものを使用して起動されたものとします。

2. 通常の方法でバックアップを実行します。 これを行う方法については、セクション23.5.8.2「NDB Cluster 管理クライアントを使用したバックアップの作成」を参照してください。

3. 各データノードでバックアップによって作成されたファイルがここに一覧表示されます。ここで、N はノード ID、B はバックアップ ID です。

   • BACKUP-B-0.N.Data

   • BACKUP-B.N.ctl

   • BACKUP-B.N.log

   これらのファイルは、各データノードの BackupDataDir /BACKUP/BACKUP-B の下にあります。 この例の残りの部分では、バックアップ ID は 1 であると想定しています。

   これらのすべてのファイルを後で新しいデータノードにコピーできるようにします (ここでは、ndb_restore によってデータノードのローカルファイルシステム上でアクセスできます)。 これらはすべて単一の場所にコピーするのが最も簡単です。これが完了したことを前提としています。

4. ターゲットクラスタの管理サーバーはホスト host20 上にあり、ターゲットには、host20 上の管理サーバー config.ini ファイルからのノード ID とホスト名が表示された 2 つのデータノードがあります:

   [ndbd]
   NodeId=3
   hostname=host3
   
   [ndbd]
   NodeId=5
   hostname=host5

   新しい (ターゲット) クラスタがクリーンデータノードファイルシステムで起動するように、host3 および host5 の各データノードプロセスは、ndbmtd -c host20 --initial または同等のものを使用して起動する必要があります。

5. 2 つの異なる 2 つのバックアップファイルのセットを各ターゲットデータノードにコピーします。 この例では、バックアップファイルを元のクラスタのノード 2 および 4 からターゲットクラスタのノード 3 にコピーします。 これらのファイルは次のとおりです:

   • BACKUP-1-0.2.Data

   • BACKUP-1.2.ctl

   • BACKUP-1.2.log

   • BACKUP-1-0.6.Data

   • BACKUP-1.6.ctl

   • BACKUP-1.6.log

   次に、バックアップファイルをノード 6 および 8 からノード 5 にコピーします。これらのファイルを次のリストに示します:

   • BACKUP-1-0.4.Data

   • BACKUP-1.4.ctl

   • BACKUP-1.4.log

   • BACKUP-1-0.8.Data

   • BACKUP-1.8.ctl

   • BACKUP-1.8.log

   この例の残りの部分では、それぞれのバックアップファイルが各ノード 3 および 5 のディレクトリ/BACKUP-1 に保存されていることを前提としています。

6. 2 つのターゲットデータノードのそれぞれで、両方のバックアップセットから復元する必要があります。 まず、次に示すように host3 で ndb_restore を起動して、ノード 2 および 4 からノード 3 にバックアップをリストアします:

   shell> ndb_restore -c host20 --nodeid=2 --backupid=1 --restore-data --backup-path=/BACKUP-1
   
   shell> ndb_restore -c host20 --nodeid=4 --backupid=1 --restore-data --backup-path=/BACKUP-1

   次に、次のように host5 で ndb_restore を起動して、ノード 6 および 8 からノード 5 にバックアップをリストアします:

   shell> ndb_restore -c host20 --nodeid=6 --backupid=1 --restore-data --backup-path=/BACKUP-1
   
   shell> ndb_restore -c host20 --nodeid=8 --backupid=1 --restore-data --backup-path=/BACKUP-1

23.4.23.2.2 元のノードより多くのノードへのリストア

特定の ndb_restore コマンドに指定されたノード ID は、元のバックアップ内のノードのノード ID であり、リストア先のデータノードのノード ID ではありません。 このセクションで説明する方法を使用してバックアップを実行する場合、ndb_restore は管理サーバーに接続し、バックアップのリストア先となるクラスタ内のデータノードのリストを取得します。 リストアされたデータは適宜分散されるため、バックアップの実行時にターゲットクラスタ内のノード数を把握または計算する必要はありません。

注記

ノードグループ当たりの LCP スレッドまたは LQH スレッドの合計数を変更する場合は、mysqldump を使用して作成されたバックアップからスキーマを再作成する必要があります。

1. データのバックアップの作成。 これを行うには、次のように、システムシェルから ndb_mgm クライアントの START BACKUP コマンドを呼び出します:

   shell> ndb_mgm -e "START BACKUP 1"

   これは、目的のバックアップ ID が 1 であることを前提としています。

2. スキーマのバックアップを作成します。 この手順は、ノードグループごとの LCP スレッドまたは LQH スレッドの合計数が変更された場合にのみ必要です。

   shell> mysqldump --no-data --routines --events --triggers --databases > myschema.sql

   重要

   ndb_mgm を使用して NDB ネイティブバックアップを作成した後は、スキーマのバックアップを作成する前にスキーマを変更しないでください (作成した場合)。

3. バックアップディレクトリを新しいクラスタにコピーします。 たとえば、リストアするバックアップの ID が 1 で、BackupDataDir = /backups/node_nodeid の場合、このノードのバックアップへのパスは/backups/node_1/BACKUP/BACKUP-1 です。 このディレクトリ内には、次の 3 つのファイルがあります:

   • BACKUP-1-0.1.Data

   • BACKUP-1.1.ctl

   • BACKUP-1.1.log

   ディレクトリ全体を新しいノードにコピーする必要があります。

   スキーマファイルを作成する必要がある場合は、これを mysqld で読み取ることができる SQL ノード上の場所にコピーします。

特定のノードからバックアップをリストアする必要はありません。

作成したばかりのバックアップからリストアするには、次のステップを実行します:

1. スキーマのリストア。

   • mysqldump を使用して別のスキーマバックアップファイルを作成した場合は、次に示すように、mysql クライアントを使用してこのファイルをインポートします:

     shell> mysql < myschema.sql

     スキーマファイルをインポートする場合、mysql クライアントが MySQL サーバーに接続できるように、表示されている内容に加えて、--user および --password のオプション (場合によってはその他) を指定する必要があります。

   • スキーマファイルを作成する必要がなかった場合は、次に示すように、ndb_restore --restore-meta (短縮形 -m) を使用してスキーマを再作成できます:

     shell> ndb_restore --nodeid=1 --backupid=1 --restore-meta --backup-path=/backups/node_1/BACKUP/BACKUP-1

     ndb_restore は管理サーバーに接続できる必要があります。これを可能にするには、必要に応じて --ndb-connectstring オプションを追加します。

2. データのリストア。 これは、元のクラスタ内のデータノードごとに、そのデータノード ID を使用するたびに 1 回実行する必要があります。 最初に 4 つのデータノードがあったと仮定すると、必要な一連のコマンドは次のようになります:

   ndb_restore --nodeid=1 --backupid=1 --restore-data --backup-path=/backups/node_1/BACKUP/BACKUP-1 --disable-indexes
   ndb_restore --nodeid=2 --backupid=1 --restore-data --backup-path=/backups/node_2/BACKUP/BACKUP-1 --disable-indexes
   ndb_restore --nodeid=3 --backupid=1 --restore-data --backup-path=/backups/node_3/BACKUP/BACKUP-1 --disable-indexes
   ndb_restore --nodeid=4 --backupid=1 --restore-data --backup-path=/backups/node_4/BACKUP/BACKUP-1 --disable-indexes

   これらはパラレルで実行できます。

   必要に応じて、--ndb-connectstring オプションを追加してください。

3. インデックスの再構築。 これらは、前述のコマンドで使用された --disable-indexes オプションによって無効化されました。 インデックスを再作成すると、リストアがすべての時点で一貫していないことによるエラーを回避できます。 インデックスを再構築すると、場合によってはパフォーマンスが向上することもあります。 インデックスを再構築するには、単一ノードで次のコマンドを 1 回実行します:

   shell> ndb_restore --nodeid=1 --backupid=1 --backup-path=/backups/node_1/BACKUP/BACKUP-1 --rebuild-indexes

   前述のように、ndb_restore が管理サーバーに接続できるように、--ndb-connectstring オプションを追加する必要がある場合があります。