この項ではバックアップの作成とそのバックアップの MySQL Cluster レプリケーションを使用した保存について説明します。レプリケーション サーバーが以前に説明 (項14.10.5. 「レプリケーションにクラスタを準備する」 およびその直後の項の説明を参照してください) した設定になっていることが前提です。その設定になっている場合、バックアップの作成およびそのバックアップの保存手順は以下のようになります。
バックアップを開始する 2 つの異なる方法があります。
方法 A:
この方法ではレプリケーションのプロセスを開始する前にクラスタのバックアップのプロセスがマスタ サーバーで有効になっている必要があります。これは以下の行を
ndb-connectstring=management_host[:port]
                をmy.cnf file の
                [MYSQL_CLUSTER]
                の項に含めること可能で、そこでは
                management_host はマスタ
                クラスタのNDB サーバーの IP
                アドレスあるいはホスト名で、port
                はマネジメント
                サーバーのポート番号です。.ポート番号はデフォルトのポート
                (1186)
                が使用されていない場合にのみ指定する必要があります。(MySQL
                Cluster
                のポートおよびポートの割り当てに関する情報は、項14.3.3. 「マルチ コンピュータの設定」
                を参照してください。)
              
この場合、そのバックアップはこのステートメントをレプリケーション マスタで実行することで開始されます。
shellM>ndb_mgm -e "START BACKUP"
方法 B:
                my.cnf
                ファイルがマネジメント
                ホストの場所を指定していない場合、バックアップ
                プロセスはこの情報を NDB
                マネジメント クライアントに START
                BACKUP
                コマンドの一部として渡すことで開始できます。以下のようになります。
              
shellM>ndb_mgmmanagement_host:port-e "START BACKUP"
                そこでは management_host
                および port
                はマネジメント
                サーバーのホスト名およびポート番号です。前に述べたようなシナリオ
                (項14.10.5. 「レプリケーションにクラスタを準備する」
                参照) で、以下のように実行できます。
              
shellM>ndb_mgm rep-master:1186 -e "START BACKUP"
どの方法の場合でも、未処理のトランザクションがある場合にはそれをバックアップを開始する前に完了し、バックアップの実施中に新たにトランザクションを実施しないようお願いします。
            クラスタおバックアップファイルを行に入れるスレーブにコピーします。マスタ
            クラスタの ndbd
            プロセスで稼動している各システムはそのシステム上にクラスタのバックアップファイルを持ち、これらのall
            のファイルは保存の確認をするためにスレーブにコピーされます。バックアップ
            ファイルは、MySQL および NDB
            バイナリがそのディレクトリの許可を読む限りスレーブ
            マネジメント
            ホストが常駐するコンピュータのどのディレクトリにコピーできます。このように、これらのファイルはディレクトリ
            /var/BACKUPS/BACKUP-1
            にコピーできるものと想定されます。
          
            スレーブ クラスタが ndbd
            プロセス (データ ノード)
            とマスタとして同じ番号を持つ必要なありませんが、この番号が同じにするように強くお勧めします。レプリケーション
            プロセスが準備不足で起動しないように、スレーブを
            --skip-slave-start
            オプションで起動することが必要です。
          
            データベースをスレーブのレプリケートされるマスタ
            クラスタのスレーブ
            クラスタで作成します。重要レプリケートされる各データベースに相当する
            CREATE SCHEMA
            ステートメントをスレーブ
            クラスタの各データ ノードで実行します。
          
MySQL Monitor のこのステートメントを使用してスレーブのクラスタをリセットします。
mysqlS>RESET SLAVE;
            スレーブの apply_status
            テーブルが保存プロセスを実行する前にレコードを含んでいないことが重要です。スレーブの
            SQL
            ステートメントを実行することでこれを実現できます。
          
mysqlS>DELETE FROM mysql.ndb_apply_status;
            ここで各バックアップ
            ファイルに対して順番に
            ndb_restore
            コマンドを使用してレプリケーション
            プロセスを開始できます。これらを実行する前に、クラスタのメタデータを保存するには
            -m
            オプションを含めることが必要です。
          
shellS>ndb_restore -cslave_host:port-nnode-id\-bbackup-id-m -rdir
            dir はバックアップ
            ファイルがレプリケーション
            スレーブの置かれるディレクトリへのパスです。残りのバックアップ
            ファイルに相当する ndb_restore
            コマンドに対しては、-m
            オプションは使用しない
            でください。
          
            マスタ クラスタからバックアップ
            ファイルがディレクトリ
            /var/BACKUPS/BACKUP-1
            にコピーされる 4 つのデータ ノード
            (項14.10. 「MySQL Cluster レプリケーション」
            の図を参照)
            に保存するには、スレーブで実行されるコマンドのシーケンスは以下のようになります。
          
shellS>ndb_restore -c rep-slave:1186 -n 2 -b 1 -m \-r ./VAR/BACKUPS/BACKUP-1shellS>ndb_restore -c rep-slave:1186 -n 3 -b 1 \-r ./VAR/BACKUPS/BACKUP-1shellS>ndb_restore -c rep-slave:1186 -n 4 -b 1 \-r ./VAR/BACKUPS/BACKUP-1shellS>ndb_restore -c rep-slave:1186 -n 5 -b 1 -e \-r ./VAR/BACKUPS/BACKUP-1
            このコマンドのシーケンスにより最も最新のエポック
            レコードをスレーブの
            ndb_apply_status
            テーブルに書き込みます。
          
            ここで最も最新のエポックをスレーブの
            ndb_binlog_index
            テーブルkら取得する必要があります(項14.10.8. 「MySQL Cluster にフェールオーバーを導入する」
            の説明参照):
          
mysqlS>SELECT @latest:=MAX(epoch)FROM mysql.ndb_binlog_index;
            @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;
            前のステップで取得下値を使用して、スレーブのmysql
            クライアントの適切な CHANGE MASTER
            TO ステートメントを発行できます。
          
mysqlS>CHANGE MASTER TO->MASTER_LOG_FILE='@file',->MASTER_LOG_POS=@pos;
            スレーブが binlog
            ファイルがマスタからデータを読み込むどのポイントかを「知って」
            いるので、この標準の MySQL
            ステートメントでスレーブにレプリケーションを開始させることができます。
          
mysqlS>START SLAVE;
バックアップを実行して二次のレプリケーション チャネルで保存するには、これらのステップを繰り返し、適切と思われる場合二次マスタおよびスレーブのホスト名および ID をプライマリのマスタおよびスレーブ レプリケーションに置き換えて、前のステートメントをそれらの上で実行するのみで可能です。
クラスタのバックアップおよびバックアップからのクラスタの保存に関する詳細は、項14.8. 「MySQL Cluster のオンライン バックアップ」 を参照してください。.

