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

BR の設計原則

このドキュメントでは、アーキテクチャとバックアップ ファイルを含む、バックアップと復元 (BR) の設計原則について説明します。

BRアーキテクチャ

BR は、各 TiKV ノードにバックアップまたは復元コマンドを送信します。コマンドを受け取った後、TiKV は対応するバックアップまたは復元操作を実行します。

各 TiKV ノードには、バックアップ操作で生成されたバックアップ ファイルが格納されるパスと、復元時に格納されたバックアップ ファイルが読み込まれるパスがあります。

br-arch

バックアップファイル

このセクションでは、BR によって生成されるバックアップ ファイルの設計について説明します。

バックアップファイルの種類

BR は、次の種類のバックアップ ファイルを生成できます。

  • SSTファイル: TiKV ノードがバックアップするデータを保存します。
  • backupmetaファイル: バックアップ ファイルの数、キー範囲、サイズ、ハッシュ (sha256) 値など、バックアップ操作のメタデータを格納します。
  • backup.lockファイル: 複数のバックアップ操作でデータが同じディレクトリに保存されるのを防ぎます。

SST ファイルの命名形式

データが Google Cloud Storage または Azure Blob Storage にバックアップされる場合、SST ファイルはstoreID_regionID_regionEpoch_keyHash_timestamp_cfの形式で名前が付けられます。フォーマットのフィールドは次のように説明されています。

  • storeIDは TiKV ノード ID です。
  • regionIDはリージョンID です。
  • regionEpochはリージョンのバージョン番号です。
  • keyHashは範囲の startKey のハッシュ (sha256) 値であり、キーの一意性を保証します。
  • timestampは、TiKV で生成されたときの SST ファイルの Unix タイムスタンプです。
  • cfは RocksDB のカラムファミリーを示します (デフォルトではdefaultまたはwrite )。

データが Amazon S3 またはネットワーク ディスクにバックアップされる場合、SST ファイルはregionID_regionEpoch_keyHash_timestamp_cfの形式で名前が付けられます。フォーマットのフィールドは次のように説明されています。

  • regionIDはリージョンID です。
  • regionEpochはリージョンのバージョン番号です。
  • keyHashは範囲の startKey のハッシュ (sha256) 値であり、キーの一意性を保証します。
  • timestampは、TiKV で生成されたときの SST ファイルの Unix タイムスタンプです。
  • cfは RocksDB のカラムファミリーを示します (デフォルトではdefaultまたはwrite )。

SST ファイルの保存形式

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

データを Google Cloud Storage または Azure Blob Storage にバックアップすると、SST ファイル、backupmeta ファイル、backup.lock ファイルが次の構造の同じディレクトリに保存されます。

.
└── 20220621
    ├── backupmeta
    |—— backup.lock
    ├── {storeID}-{regionID}-{regionEpoch}-{keyHash}-{timestamp}-{cf}.sst
    ├── {storeID}-{regionID}-{regionEpoch}-{keyHash}-{timestamp}-{cf}.sst
    └── {storeID}-{regionID}-{regionEpoch}-{keyHash}-{timestamp}-{cf}.sst

データを Amazon S3 またはネットワーク ディスクにバックアップすると、SST ファイルは storeID に基づいてサブディレクトリに保存されます。構造は次のとおりです。

.
└── 20220621
    ├── backupmeta
    |—— backup.lock
    ├── store1
    │   └── {regionID}-{regionEpoch}-{keyHash}-{timestamp}-{cf}.sst
    ├── store100
    │   └── {regionID}-{regionEpoch}-{keyHash}-{timestamp}-{cf}.sst
    ├── store2
    │   └── {regionID}-{regionEpoch}-{keyHash}-{timestamp}-{cf}.sst
    ├── store3
    ├── store4
    └── store5