BR の設計原則

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

BRアーキテクチャ

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

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

バックアップファイル

このセクションでは、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 ファイルの保存形式

• SST ファイルの保存形式の詳細については、 Rocksdb BlockBasedTable フォーマットを参照してください。
• SST ファイルのバックアップ データのエンコード形式の詳細については、 テーブル データの Key-Value へのマッピングを参照してください。

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

データを 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