ポイントインタイム リカバリ

ポイントインタイム リカバリ (PITR) を使用すると、TiDB クラスターのスナップショットを過去の任意の時点から新しいクラスターに復元できます。 v6.2.0 で、TiDB は PITR in 復元する (BR) を導入します。

PITR を使用して、次のビジネス要件を満たすことができます。

• 災害復旧の目標復旧時点 (RPO) を 20 分未満に短縮します。
• エラー イベントの前の時点にデータをロールバックすることにより、アプリケーションからの誤った書き込みのケースを処理します。
• 履歴データの監査を実施し、法規制の要件を満たします。

このドキュメントでは、PITR の設計、機能、およびアーキテクチャについて紹介します。 PITR の使用方法を学習する必要がある場合は、 PITR の使用シナリオを参照してください。

ビジネスで PITR を使用する

ブラジルは PITR 機能を提供します。 BRでは、データのバックアップ（スナップショットバックアップ、ログバックアップ）、指定時点へのワンクリックリストア、バックアップデータの管理など、PITRのすべての操作を行うことができます。

ビジネスでPITRを使用する手順は次のとおりです。

バックアップデータ

PITR を達成するには、次のバックアップ タスクを実行する必要があります。

• ログ バックアップ タスクを開始します。 br log startコマンドを実行して、ログ バックアップ タスクを開始できます。このタスクは、TiDB クラスターのバックグラウンドで実行され、KV ストレージの変更ログをバックアップ ストレージに自動的にバックアップします。
• スナップショット (フル) バックアップを定期的に実行します。 br backup fullコマンドを実行して、指定した時点 (毎日 00:00 など) にクラスター スナップショットをバックアップ ストレージにバックアップできます。

ワンクリックでデータを復元

PITR を使用してデータを復元するには、 br restore pointコマンドを実行して復元プログラムを実行する必要があります。プログラムは、スナップショット バックアップとログ バックアップからデータを読み取り、指定された時点のデータを新しいクラスターに復元します。

br restore pointコマンドを実行する場合、復元したい時点より前の最新のスナップショット バックアップ データを指定し、ログ バックアップ データを指定する必要があります。 BR は、最初にスナップショット データを復元し、次にスナップショット時点と指定された復元時点の間のログ バックアップ データを読み取ります。

バックアップ データの管理

PITR のバックアップ データを管理するには、バックアップ データを格納するためのバックアップ ディレクトリ構造を設計し、古くなったバックアップ データや不要になったバックアップ データを定期的に削除する必要があります。

• バックアップ データを次の構造で編成します。

  • スナップショット バックアップとログ バックアップを同じディレクトリに格納して、一元管理します。たとえば、 backup-${cluster-id}です。
  • 各スナップショット バックアップは、名前にバックアップ日付が含まれるディレクトリに保存します。たとえば、 backup-${cluster-id}/snapshot-20220512000130です。
  • ログ バックアップを固定ディレクトリに保存します。たとえば、 backup-${cluster-id}/log-backupです。

• 古くなった、または不要になったバックアップ データを削除します。

  • スナップショット バックアップを削除すると、スナップショット バックアップのディレクトリを削除できます。
  • 指定した時点より前のログ バックアップを削除するには、 br log truncateコマンドを実行します。

機能

• PITR ログ バックアップは、クラスターに 5% の影響を与えます。
• ログとスナップショットを同時にバックアップすると、クラスターへの影響は 20% 未満になります。
• 各 TiKV ノードで、PITR は 280 GB/h でスナップショット データを復元し、30 GB/h でログ データを復元できます。
• PITR を使用すると、ディザスタ リカバリの RPO は 20 分未満になります。復元するデータのサイズに応じて、目標復旧時間 (RTO) は数分から数時間まで異なります。
• BR は、600 GB/h の速度で古いログ バックアップ データを削除します。

ノート：

• 上記の機能仕様は、次の 2 つのテスト シナリオのテスト結果に基づいています。実際のデータは異なる場合があります。
• スナップショット データの復元速度 = スナップショット データのサイズ / (期間 * TiKV ノードの数)
• ログデータの復元速度 = 復元されたログデータのサイズ / (期間 * TiKV ノードの数)

テスト シナリオ 1 ( TiDB Cloudで):

• TiKV ノード数 (8 コア、16 GB メモリ): 21
• リージョン数: 183,000
• クラスターで作成された新しいログ: 10 GB/h
• 書き込み (挿入/更新/削除) QPS: 10,000

テスト シナリオ 2 (オンプレミス):

• TiKV ノード数 (8 コア、64 GB メモリ): 6
• リージョン数: 50,000
• クラスターで作成された新しいログ: 10 GB/h
• 書き込み (挿入/更新/削除) QPS: 10,000

制限事項

• 1 つのクラスターで実行できるログ バックアップ タスクは 1 つだけです。
• 空のクラスターにのみデータを復元できます。クラスターのサービスとデータへの影響を避けるために、PITR をインプレースまたは空でないクラスターで実行しないでください。
• バックアップ データは、共有ファイル システム (NFS など)、Amazon S3、GCS、または Azure Blob Storage に保存できます。
• クラスター レベルの PITR のみを実行できます。データベース レベルおよびテーブル レベルの PITR はサポートされていません。
• ユーザー テーブルまたは権限テーブルのデータを復元することはできません。
• バックアップ クラスタに TiFlash レプリカがある場合、PITR を実行した後、復元クラスタには TiFlash レプリカのデータが含まれません。代わりに、データが TiKV ノードから複製されるまでに一定の時間がかかります。このため、PITR がデータの復元を完了した後、TiFlash はすぐには利用できません。
• アップストリーム データベースが TiDB Lightning の物理インポート モードを使用してデータをインポートする場合、ログ バックアップでデータをバックアップすることはできません。データのインポート後に完全バックアップを実行することをお勧めします。詳細については、 アップストリーム データベースはTiDB Lightning Physical Mode を使用してデータをインポートしますを参照してください。
• 一定期間のログバックアップデータを繰り返し復元しないでください。範囲[t1=10, t2=20)のログ バックアップ データを繰り返し復元すると、復元されたデータが不整合になる可能性があります。
• その他の既知の制限については、 PITR の既知の問題を参照してください。

バージョンの互換性チェック

v6.3.0 では、PITR 後に生成されたバックアップ ファイルが新しい方法で圧縮されます。小さなファイルは保存する前にマージされます (小さなファイルが多すぎることによる問題を解決するため)。ただし、以前のバージョンの TiDB クラスターは、v6.3 クラスターで生成されたバックアップ データと互換性がありません。次の表を参照してください。

アーキテクチャ

PITR は、スナップショットのバックアップと復元、およびログのバックアップと復元に使用されます。スナップショットのバックアップと復元については、 BR の設計原則を参照してください。このセクションでは、ログのバックアップと復元の実装について説明します。

ログのバックアップと復元は、次のように実装されます。

ログ バックアップ タスクが実行されると、次のようになります。

1. BR はbr log startコマンドを受信します。
2. BR はログ バックアップ タスクを PD に登録し、ログ バックアップ メタデータを PD に保存します。
3. TiKV バックアップ エグゼキュータ モジュールは、PD でのログ バックアップ タスクの作成をリッスンします。ログ バックアップ タスクの作成を検出すると、ログ バックアップの実行を開始します。
4. TiKV バックアップ実行モジュールは、KV データの変更を読み取り、ローカル SST ファイルに書き込みます。
5. TiKV バックアップ実行モジュールは、SST ファイルを定期的にバックアップ ストレージに書き込み、バックアップ ストレージ内のメタデータを更新します。

ログ復元タスクが実行されると、次のようになります。

1. BR はbr log restoreコマンドを受信します。
2. BR は、バックアップ ストレージからログ バックアップ データを読み取り、復元が必要なログ バックアップ データを計算してフィルタリングします。
3. BR は、ログ バックアップ データを復元するための領域 (分割領域) を作成し、その領域を対応する TiKV ノードにスケジュールする (分散領域) ように PD に要求します。
4. PD がスケジューリングを完了すると、BR は復元要求を各 TiKV 復元実行モジュールに送信します。
5. TiKV 復元エグゼキュータ モジュールは、バックアップ ストレージからログ バックアップ データをダウンロードし、対応するリージョンにデータを書き込みます。

もっと詳しく知る

• BR を使用してログのバックアップと復元を実行する
• PITR を使用する
• PITR モニタリングとアラート