TiDB Cloud
TiDB Self-Managed
Learning Center
お問い合わせ

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 ノードからリストア結果を受け取ります。

    • TiKV ノードがダウンしているなど、 RegionNotFoundまたはEpochNotMatch原因で一部のデータの復元に失敗した場合、 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

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