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

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

ポイントインタイムリカバリ (つまり、特定の時点よりあとに行われたデータ変更のリカバリ) は、サーバーをバックアップが行われた時点の状態に戻す完全バックアップのリストア後に実行されます。 「NDB Cluster」および「NDB Cluster」レプリケーションを使用して「NDB Cluster」テーブルの point-in-time リカバリを実行するには、ネイティブの NDB データバックアップ (ndb_mgm クライアントで CREATE BACKUP を発行して取得) を使用し、ndb_binlog_index テーブルを (mysqldump を使用して作成したダンプからリストアします。

NDB Cluster のポイントインタイムリカバリを実行するには、次に示す手順に従う必要があります:

1. ndb_mgm クライアントで START BACKUP コマンドを使用して、クラスタ内のすべての NDB データベースをバックアップします (セクション23.5.8「NDB Cluster のオンラインバックアップ」を参照してください)。

2. その後の時点でクラスタをリストアする前に、mysql.ndb_binlog_index テーブルのバックアップを作成します。 このタスクに mysqldump を使用することが、おそらくもっとも簡単です。 このときに、バイナリログファイルもバックアップします。

   このバックアップは、必要に応じて定期的 (等間隔で 1 時間ごとなど) に更新してください。

3. (重大な障害またはエラーが発生します。)

4. 最新の既知の良好なバックアップを探します。

5. データノードのファイルシステムをクリアします (ndbd --initial または ndbmtd --initial を使用します)。

   注記

   NDB 8.0.21 以降、「ディスクデータ」テーブルスペースおよびログファイルは --initial によって削除されます。 以前は、これらを手動で削除する必要がありました。

6. mysql.ndb_binlog_index テーブルで DROP TABLE または TRUNCATE TABLE を使用します。

7. ndb_restore を実行して、すべてのデータをリストアします。 ndb_apply_status テーブルが正しく移入されるように、ndb_restore の実行時に --restore-epoch オプションを含める必要があります。 (詳細については、セクション23.4.23「ndb_restore — NDB Cluster バックアップの復元」を参照してください。)

8. 必要に応じて、mysqldump の出力から ndb_binlog_index テーブルをリストアしたり、バックアップからバイナリログファイルをリストアしたりします。

9. 最後に適用されたエポック (すなわち、ndb_apply_status テーブルの epoch カラムの最大値) をユーザー変数 @LATEST_EPOCH として検索します (重要)。

   SELECT @LATEST_EPOCH:=MAX(epoch)
       FROM mysql.ndb_apply_status;

10. ndb_binlog_index テーブルの @LATEST_EPOCH に対応する、最新のバイナリログファイル (@FIRST_FILE) と位置 (Position カラム値) をこのファイル内で検索します。

    SELECT Position, @FIRST_FILE:=File
        FROM mysql.ndb_binlog_index
        WHERE epoch > @LATEST_EPOCH ORDER BY epoch ASC LIMIT 1;

11. mysqlbinlog を使用して、障害が発生した時点まで、特定のファイルと位置からバイナリログイベントを再現します。 (セクション4.6.8「mysqlbinlog — バイナリログファイルを処理するためのユーティリティー」を参照してください。)

バイナリログ、レプリケーション、および増分リカバリに関する詳細は、セクション7.5「Point-in-Time (増分) リカバリ」も参照してください。