18.6.9 MySQL Cluster レプリケーションを使用した MySQL Cluster バックアップ

[+/-]

18.6.9.1 MySQL Cluster レプリケーション: レプリケーションスレーブとマスターのバイナリログとの同期の自動化

18.6.9.2 MySQL Cluster レプリケーションを使用したポイントインタイムリカバリ

このセクションでは、バックアップの作成と、バックアップからの MySQL Cluster レプリケーションを使用したリストアについて説明します。レプリケーションサーバーは、前に説明したとおりにすでに構成されたものとします (セクション18.6.5「レプリケーションのための MySQL Cluster の準備」およびその直後のセクションを参照してください)。これがすでに行われている場合、バックアップを作成してそのバックアップからリストアする手順は次のとおりです。

1. バックアップを開始するには、2 つの異なる方法があります。

   • 方法 A  この方法では、レプリケーションプロセスを開始する前に、クラスタのバックアッププロセスがマスターサーバーで有効になっている必要があります。これを行うには、my.cnf file の [mysql_cluster] セクションに次の行を加えます。ここで、management_host はマスタークラスタに対する NDB 管理サーバーの IP アドレスまたはホスト名であり、port は管理サーバーのポート番号です。

     ndb-connectstring=management_host[:port]

     注記

     ポート番号は、デフォルトのポート (1186) が使用されていない場合にのみ、指定する必要があります。MySQL Cluster でのポートおよびポートの割り当てに関する詳細は、セクション18.2.4「MySQL Cluster の初期構成」を参照してください。

     この場合、バックアップは、このステートメントをレプリケーションマスターで実行すると起動できます。

     shellM> ndb_mgm -e "START BACKUP"

   • 方法 B  my.cnf ファイルで、管理ホストを検出する場所が指定されていない場合、START BACKUP コマンドの一部としてこの情報を NDB 管理クライアントに渡すことで、バックアッププロセスを起動できます。ここで示すように、これを実行できます。ここで、management_host と port は管理サーバーのホスト名とポート番号です。

     shellM> ndb_mgm management_host:port -e "START BACKUP"

     前に述べたようなシナリオの場合 (セクション18.6.5「レプリケーションのための MySQL Cluster の準備」を参照してください)、これは次のように実行されます。

     shellM> ndb_mgm rep-master:1186 -e "START BACKUP"

2. オンラインにされているスレーブにクラスタのバックアップファイルをコピーします。マスタークラスタの ndbd プロセスを動作している各システムには、そのシステム上にクラスタのバックアップファイルが配置され、これらのすべてのファイルがスレーブにコピーされ、正常なリストアを確実に行う必要があります。バックアップファイルは、スレーブの管理ホストが存在するコンピュータ上のどのディレクトリにもコピーできますが、MySQL および NDB バイナリがそのディレクトリの読み取り権限を持っている場合にかぎります。このケースでは、このファイルがディレクトリ /var/BACKUPS/BACKUP-1 にコピーされたものとします。

   スレーブクラスタがマスターと同じ ndbd プロセス (データノード) 番号を持つ必要はありませんが、この番号を同じ番号にすることを強くお勧めします。レプリケーションプロセスの不適切な起動を防ぐには、スレーブを --skip-slave-start オプションで起動する必要があります。

3. マスタークラスタに存在し、スレーブに複製するデータベースをスレーブクラスタに作成します。

   重要

   複製する各データベースに対応する CREATE DATABASE (または CREATE SCHEMA) ステートメントは、スレーブクラスタの各 SQL ノードで実行します。

4. MySQL Monitor でこのステートメントを使用してスレーブクラスタをリセットします。

   mysqlS> RESET SLAVE;

   リストアプロセスを実行する前に、スレーブの ndb_apply_status テーブルにレコードが含まれていないことを確認することが重要です。これを行うには、スレーブでこの SQL ステートメントを実行します。

   mysqlS> DELETE FROM mysql.ndb_apply_status;

5. これで、各バックアップファイルに対して順番に ndb_restore コマンドを使用して、レプリケーションスレーブでクラスタのリストアプロセスを起動できます。このプロセスの最初に、クラスタのメタデータをリストアするための -m オプションを加える必要があります。

   shellS> ndb_restore -c slave_host:port -n node-id \
           -b backup-id -m -r dir

   dir は、バックアップファイルがレプリケーションスレーブに置かれたディレクトリへのパスです。残りのバックアップファイルに対応する ndb_restore コマンドに、-m オプションを使用しないでください。

   バックアップファイルがディレクトリ /var/BACKUPS/BACKUP-1 にコピーされた場所である 4 つのデータノード (セクション18.6「MySQL Cluster レプリケーション」 の図に表示されているとおりです) を使用してマスタークラスタからリストアする場合、スレーブで実行されるコマンドの正しいシーケンスは、次のようになります。

   shellS> ndb_restore -c rep-slave:1186 -n 2 -b 1 -m \
           -r ./var/BACKUPS/BACKUP-1
   shellS> ndb_restore -c rep-slave:1186 -n 3 -b 1 \
           -r ./var/BACKUPS/BACKUP-1
   shellS> ndb_restore -c rep-slave:1186 -n 4 -b 1 \
           -r ./var/BACKUPS/BACKUP-1
   shellS> ndb_restore -c rep-slave:1186 -n 5 -b 1 -e \
           -r ./var/BACKUPS/BACKUP-1

   重要

   エポックがスレーブの mysql.ndb_apply_status に書き込まれるには、この例の ndb_restore の最後の起動に -e (または --restore_epoch) オプションが必要です。この情報がないと、スレーブはマスターと適切に同期を取れなくなります。(セクション18.4.20「ndb_restore — MySQL Cluster バックアップのリストア」を参照してください。)

6. ここで、スレーブの ndb_apply_status テーブルから最新のエポックを取得する必要があります (セクション18.6.8「MySQL Cluster レプリケーションを使用したフェイルオーバーの実装」で説明したとおりです)。

   mysqlS> SELECT @latest:=MAX(epoch)
           FROM mysql.ndb_apply_status;

7. 前のステップで取得したエポック値として @latest を使用すると、ここで示したクエリーを使用して、マスターの mysql.ndb_binlog_index テーブルから正しいバイナリログファイル @file の正しい起動位置 @pos を取得できます。

   mysqlM> SELECT
        ->     @file:=SUBSTRING_INDEX(File, '/', -1),
        ->     @pos:=Position
        -> FROM mysql.ndb_binlog_index
        -> WHERE epoch > @latest
        -> ORDER BY epoch ASC LIMIT 1;

   現在レプリケーショントラフィックがない場合、マスターで SHOW MASTER STATUS を実行して、File カラムに表示されるすべてのファイルに対していちばん大きな値のサフィクスを持つ名前のファイルの Position カラムの値を使用すると、この情報を取得できます。ただしこの場合、これを指定し、その内容を次のステップで手動で指定するか、スクリプトで出力を解析して指定する必要があります。

8. 前のステップで取得した値を使用すると、スレーブの mysql クライアントで適切な CHANGE MASTER TO ステートメントを発行できるようになります。

   mysqlS> CHANGE MASTER TO
        ->     MASTER_LOG_FILE='@file',
        ->     MASTER_LOG_POS=@pos;

9. スレーブはどのバイナリログファイルのどの点から読み取りを開始するかがマスターから「わかる」ようになるため、スレーブはこの標準 MySQL ステートメントで複製を開始できます。

   mysqlS> START SLAVE;

セカンダリレプリケーションチャネルでバックアップとリストアを実行するために必要なことは、必要に応じて、プライマリのマスターとスレーブのレプリケーションサーバーのホスト名と ID に代わって、セカンダリのマスターとスレーブのホスト名と ID を使用し、前述のステートメントを実行するステップを繰り返すだけです。

クラスタのバックアップの実行とバックアップからのクラスタのリストアに関する詳細は、セクション18.5.3「MySQL Cluster のオンラインバックアップ」を参照してください。