TiDB Cloud
TiDB Self-Managed
Learning Center
お問い合わせ
🚀
新しい TiDB Labs を探索し、ブラウザから直接分散型 SQL データベースを学び、RAG アプリを構築しましょう。

TiDB ログ バックアップと PITRアーキテクチャ

このドキュメントでは、例としてバックアップと復元 ( BR ) ツールを使用して、TiDB ログ バックアップとポイント イン タイム リカバリ (PITR) のアーキテクチャとプロセスを紹介します。

アーキテクチャ

ログ バックアップと PITR のアーキテクチャは次のとおりです。

BR log backup and PITR architecture

ログバックアップのプロセス

クラスタ ログ バックアップのプロセスは次のとおりです。

BR log backup process design

ログ バックアップ プロセスに関連するシステム コンポーネントと主要な概念:

  • ローカル メタデータ: ローカル チェックポイント ts、グローバル チェックポイント ts、およびバックアップ ファイル情報を含む、単一の TiKV ノードによってバックアップされたメタデータを示します。
  • ローカル チェックポイント ts (ローカル メタデータ内): この TiKV ノードのローカル チェックポイント ts より前に生成されたすべてのログがターゲットstorageにバックアップされたことを示します。
  • グローバル チェックポイント ts : すべての TiKV ノードでグローバル チェックポイント ts の前に生成されたすべてのログがターゲットstorageにバックアップされたことを示します。 TiDB Coordinator は、すべての TiKV ノードのローカル チェックポイント ts を収集してこのタイムスタンプを計算し、PD に報告します。
  • TiDB コーディネーター: TiDB ノードがコーディネーターとして選出され、ログ バックアップ タスク全体 (グローバル チェックポイント ts) の進行状況の収集と計算を担当します。このコンポーネントは設計上ステートレスであり、障害が発生すると、生き残った TiDB ノードから新しいコーディネーターが選出されます。
  • TiKV ログ バックアップ オブザーバー: TiDB クラスター内の各 TiKV ノードで実行され、ログ データのバックアップを担当します。 TiKV ノードに障害が発生した場合、そのデータ範囲のバックアップはリージョンの再選択後に他の TiKV ノードに引き継がれ、これらのノードはグローバル チェックポイント ts から始まる障害範囲のデータをバックアップします。

完全なバックアップ プロセスは次のとおりです。

  1. BR はbr log startコマンドを受信します。

    • BR は、チェックポイント ts (ログ バックアップの開始時刻) とバックアップ タスクのstorageパスを解析します。
    • ログバックアップタスクの登録: BR がログバックアップタスクを PD に登録します。

  2. TiKV は、ログ バックアップ タスクの作成と更新を監視します。

    • ログ バックアップ タスクのフェッチ: 各 TiKV ノードのログ バックアップ オブザーバーは、PD からログ バックアップ タスクをフェッチし、指定された範囲のログ データをバックアップします。

  3. ログ バックアップ オブザーバーは、KV 変更ログを継続的にバックアップします。

    • kv 変更データの読み取り: KV 変更データを読み取り、変更ログをカスタム形式のバックアップ ファイルに保存します。
    • Fetch global checkpoint ts : PD からグローバル チェックポイント ts をフェッチします。
    • ローカル メタデータの生成: ローカル チェックポイント ts、グローバル チェックポイント ts、およびバックアップ ファイル情報を含む、バックアップ タスクのローカル メタデータを生成します。
    • ログ データとメタデータのアップロード: バックアップ ファイルとローカル メタデータをターゲットstorageに定期的にアップロードします。
    • GC の構成: バックアップされていない (ローカル チェックポイント ts より大きい) データがTiDB GC メカニズムによってリサイクルされないように PD に要求します。

  4. TiDB Coordinator は、ログ バックアップ タスクの進行状況を監視します。

    • バックアップの進行状況を監視する: すべての TiKV ノードをポーリングして、各リージョン(リージョンチェックポイント ts) のバックアップの進行状況を取得します。
    • レポート グローバル チェックポイント ts :リージョンチェックポイント ts に基づいて、ログ バックアップ タスク全体 (グローバル チェックポイント ts) の進行状況を計算し、グローバル チェックポイント ts を PD にレポートします。

  5. PD はログ バックアップ タスクのステータスを保持し、 br log statusを使用して表示できます。

PITRのプロセス

PITR のプロセスは次のとおりです。

Point-in-time recovery process design

完全な PITR プロセスは次のとおりです。

  1. BR はbr restore pointコマンドを受信します。

    • BR は、完全バックアップ データ アドレス、ログ バックアップ データ アドレス、およびポイント イン タイム リカバリ時刻を解析します。
    • バックアップ データ内の復元オブジェクト (データベースまたはテーブル) を照会し、復元するテーブルが存在し、復元要件を満たしているかどうかを確認します。

  2. BR は完全なバックアップ データを復元します。

  3. BR は、ログ バックアップ データを復元します。

    • バックアップ データの読み取り: ログ バックアップ データを読み取り、復元する必要があるログ バックアップ データを計算します。
    • Fetch リージョン info : PD にアクセスして、すべての地域ディストリビューションを取得します。
    • データの復元を TiKV に要求する: ログの復元要求を作成し、対応する TiKV ノードに送信します。ログ復元要求には、復元するログ バックアップ データ情報が含まれます。

  4. TiKV はBRからの復元要求を受け入れ、ログ復元ワーカーを開始します。

    • ログ復元ワーカーは、復元する必要があるログ バックアップ データを取得します。

  5. TiKV は、ログ バックアップ データを復元します。

    • Download KVs : ログ復元ワーカーは、ログ復元要求に従って、対応するバックアップ データをバックアップstorageからローカル ディレクトリにダウンロードします。
    • Rewrite KVs : ログ復元ワーカーは、復元クラスター テーブルのテーブル ID に従って、バックアップ データの KV データを書き換えます。つまり、 キー値の元のテーブル ID を新しいテーブル ID に置き換えます。復元ワーカーも同様にインデックス ID を書き換えます。
    • Apply KVs : ログ復元ワーカーは、処理された KV データを raft インターフェースを介してストア (RocksDB) に書き込みます。
    • 復元結果の報告: ログ復元ワーカーは復元結果をBRに返します。

  6. BR は、各 TiKV ノードから復元結果を受け取ります。

    • RegionNotFoundまたはEpochNotMatchが原因で一部のデータの復元に失敗した場合 (たとえば、TiKV ノードがダウンしている場合)、 BRは復元を再試行します。
    • 復元に失敗し、再試行できないデータがある場合、復元タスクは失敗します。
    • すべてのデータが復元されると、復元タスクは成功します。

ログ バックアップ ファイル

ログ バックアップでは、次の種類のファイルが生成されます。

  • {min_ts}-{uuid}.logファイル: バックアップ タスクの KV 変更ログ データを保存します。 {min_ts}はファイル内の KV 変更ログ データの最小 TSO タイムスタンプで、 {uuid}はファイルの作成時にランダムに生成されます。
  • {checkpoint_ts}-{uuid}.metaファイル: 各 TiKV ノードがログ バックアップ データをアップロードするたびに生成され、今回アップロードされたすべてのログ バックアップ データ ファイルのメタデータを格納します。 {checkpoint_ts}は TiKV ノードのログ バックアップ チェックポイントであり、グローバル チェックポイントはすべての TiKV ノードの最小チェックポイントです。 {uuid}は、ファイルの作成時にランダムに生成されます。
  • {store_id}.tsファイル: このファイルは、各 TiKV ノードがログ バックアップ データをアップロードするたびにグローバル チェックポイント ts で更新されます。 {store_id}は TiKV ノードのストア ID です。
  • v1_stream_truncate_safepoint.txtファイル: br log truncateによって削除されたstorage内の最新のバックアップ データに対応するタイムスタンプを格納します。

バックアップファイルの構造

.
├── v1
│   ├── backupmeta
│   │   ├── {min_restored_ts}-{uuid}.meta
│   │   ├── {checkpoint}-{uuid}.meta
│   ├── global_checkpoint
│   │   ├── {store_id}.ts
│   ├── {date}
│   │   ├── {hour}
│   │   │   ├── {store_id}
│   │   │   │   ├── {min_ts}-{uuid}.log
│   │   │   │   ├── {min_ts}-{uuid}.log
├── v1_stream_truncate_safepoint.txt

次に例を示します。

.
├── v1
│   ├── backupmeta
│   │   ├── ...
│   │   ├── 435213818858112001-e2569bda-a75a-4411-88de-f469b49d6256.meta
│   │   ├── 435214043785779202-1780f291-3b8a-455e-a31d-8a1302c43ead.meta
│   │   ├── 435214443785779202-224f1408-fff5-445f-8e41-ca4fcfbd2a67.meta
│   ├── global_checkpoint
│   │   ├── 1.ts
│   │   ├── 2.ts
│   │   ├── 3.ts
│   ├── 20220811
│   │   ├── 03
│   │   │   ├── 1
│   │   │   │   ├── ...
│   │   │   │   ├── 435213866703257604-60fcbdb6-8f55-4098-b3e7-2ce604dafe54.log
│   │   │   │   ├── 435214023989657606-72ce65ff-1fa8-4705-9fd9-cb4a1e803a56.log
│   │   │   ├── 2
│   │   │   │   ├── ...
│   │   │   │   ├── 435214102632857605-11deba64-beff-4414-bc9c-7a161b6fb22c.log
│   │   │   │   ├── 435214417205657604-e6980303-cbaa-4629-a863-1e745d7b8aed.log
│   │   │   ├── 3
│   │   │   │   ├── ...
│   │   │   │   ├── 435214495848857605-7bf65e92-8c43-427e-b81e-f0050bd40be0.log
│   │   │   │   ├── 435214574492057604-80d3b15e-3d9f-4b0c-b133-87ed3f6b2697.log
├── v1_stream_truncate_safepoint.txt

このページは役に立ちましたか？