📣

TiDB Cloud Serverless が
Starter
に変わりました!このページは自動翻訳されたものです。
原文はこちらからご覧ください。

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 コーディネーターは、すべての 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 変更データを読み取り、変更ログをカスタム形式のバックアップファイルに保存します。
    • グローバル チェックポイント ts を取得: PD からグローバル チェックポイント ts を取得します。
    • ローカル メタデータの生成: ローカル チェックポイント ts、グローバル チェックポイント ts、バックアップ ファイル情報など、バックアップ タスクのローカル メタデータを生成します。
    • ログ データとメタデータのアップロード: バックアップ ファイルとローカル メタデータを定期的にターゲットstorageにアップロードします。
    • GC を構成する: バックアップされていないデータ (ローカル チェックポイント ts より大きい) がTiDB GCメカニズムによってリサイクルされるのを防ぐように PD に要求します。
  4. TiDB コーディネーターは、ログ バックアップ タスクの進行状況を監視します。

    • バックアップの進行状況を監視する: すべての 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 はログバックアップデータを復元します。

    • バックアップ データの読み取り: ログ バックアップ データを読み取り、復元する必要があるログ バックアップ データを計算します。
    • リージョン情報の取得: PD にアクセスしてすべてのリージョン分布を取得します。
    • TiKVにデータの復元を要求する:ログ復元要求を作成し、対応するTiKVノードに送信します。ログ復元要求には、復元するログバックアップデータの情報が含まれます。
  4. TiKV はBRからの復元要求を受け入れ、ログ復元ワーカーを開始します。

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

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

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

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

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

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

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

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

バックアップ ファイルのディレクトリ構造の説明:

  • backupmeta : バックアップメタデータを保存します。ファイル名のresolved_tsバックアップの進行状況を示し、このTSO以前のデータが完全にバックアップされていることを意味します。ただし、このTSOは特定のシャードの進行状況のみを反映することに注意してください。
  • global_checkpoint : グローバルバックアップの進行状況を表します。2 br restore point使用してデータを復元できる最新の時点を記録します。
  • {date}/{hour} : 対応する日時のバックアップデータを保存します。storageをクリーンアップする際は、手動でデータを削除するのではなく、必ずbr log truncate使用してください。メタデータはこのディレクトリ内のデータを参照しており、手動で削除すると復元が失敗したり、復元後にデータの不整合が発生したりする可能性があるためです。

次に例を示します。

. ├── 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

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