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 ファイルの保存形式

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