TiDB スナップショットのバックアップおよび復元のアーキテクチャ

このドキュメントでは、例としてバックアップ & リストア ( BR ) ツールを使用した TiDB スナップショットのバックアップとリストアのアーキテクチャとプロセスを紹介します。

アーキテクチャ

TiDB スナップショットのバックアップと復元のアーキテクチャは次のとおりです。

BR snapshot backup and restore architecture

バックアップのプロセス

クラスターのスナップショットバックアップのプロセスは次のとおりです。

snapshot backup process design

完全なバックアッププロセスは次のとおりです。

BRはbr backup fullコマンドを受信します。
- バックアップの時点とstorageのパスを取得します。
BR はデータのバックアップをスケジュールします。
- GC の一時停止: BR は、バックアップデータがTiDB GC メカニズムによってクリーンアップされないように TiDB GC 時間を設定します。
- TiKV およびリージョン情報の取得: BR はPD にアクセスして、すべての TiKV ノードのアドレスとデータのリージョンを取得します。
- TiKV にデータのバックアップを要求する: BR はバックアップ要求を作成し、それをすべての TiKV ノードに送信します。バックアップ要求には、バックアップ時点、バックアップ対象のリージョン、およびstorageパスが含まれます。
TiKV はバックアップ要求を受け入れ、バックアップワーカーを開始します。
TiKV はデータをバックアップします。
- KV のスキャン: バックアップワーカーは、リーダーが配置されているリージョンからバックアップ時点に対応するデータを読み取ります。
- SST の生成: バックアップワーカーはデータを SST ファイルに保存し、メモリに保存します。
- SST のアップロード: バックアップワーカーは、SST ファイルをstorageパスにアップロードします。
BR は各 TiKV ノードからバックアップ結果を受信します。
- TiKV ノードがダウンしているなど、リージョンの変更により一部のデータのバックアップに失敗した場合、 BR はバックアップを再試行します。
- バックアップに失敗し、再試行できないデータがある場合、バックアップタスクは失敗します。
- すべてのデータがバックアップされた後、 BR はメタデータをバックアップします。
BR はメタデータをバックアップします。
- スキーマのバックアップ: BR はテーブルスキーマをバックアップし、テーブルデータのチェックサムを計算します。
- メタデータのアップロード: BR はバックアップメタデータを生成し、storageパスにアップロードします。バックアップメタデータには、バックアップタイムスタンプ、テーブルと対応するバックアップファイル、データチェックサム、ファイルチェックサムが含まれます。

復元のプロセス

クラスターのスナップショット復元のプロセスは次のとおりです。

snapshot restore process design

完全な復元プロセスは次のとおりです。

BRはbr restoreコマンドを受信します。
- データstorageパスと復元するデータベースまたはテーブルを取得します。
- リストア対象のテーブルが存在するか、リストアの要件を満たしているかを確認します。
BR はデータの復元をスケジュールします。
- リージョンスケジュールの一時停止: BR は、復元中に自動リージョンスケジュールを一時停止するように PD に要求します。
- スキーマの復元: BR は、バックアップデータと復元するデータベースおよびテーブルのスキーマを取得します。新規に作成したテーブルのIDはバックアップデータのIDと異なる場合があるので注意してください。
- 分割および分散リージョン: BR は、バックアップデータに基づいて領域を割り当てるように PD に要求し (分割リージョン)、領域がstorageノードに均等に分散されるようにスケジュールします (分散リージョン)。各リージョンには指定されたデータ範囲があります[start key, end key) 。
- TiKV にデータの復元を要求する: BR は復元要求を作成し、リージョン分割の結果に従って対応する TiKV ノードに送信します。復元リクエストには、復元するデータと書き換えルールが含まれます。
TiKV は復元リクエストを受け入れ、復元ワーカーを開始します。
- リストアワーカーは、リストアするために読み取る必要があるバックアップデータを計算します。
TiKV がデータを復元します。
- SST のダウンロード: リストアワーカーは、対応する SST ファイルをstorageパスからローカルディレクトリにダウンロードします。
- KV の書き換え: 復元ワーカーは、新しいテーブル ID に従って KV データを書き換えます。つまり、キーと値の元のテーブル ID を新しいテーブル ID に置き換えます。復元ワーカーも同様にインデックス ID を書き換えます。
- SSTの取り込み: リストアワーカーは、処理された SST ファイルを RocksDB に取り込みます。
- 復元結果の報告: 復元ワーカーは復元結果をBRに報告します。
BR は各 TiKV ノードからリストア結果を受け取ります。
- TiKV ノードがダウンしているなど、 RegionNotFoundまたはEpochNotMatch原因で一部のデータの復元に失敗した場合、 BR は復元を再試行します。
- 復元に失敗し、再試行できないデータがある場合、復元タスクは失敗します。
- すべてのデータが復元されると、復元タスクは成功します。

バックアップファイル

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

スナップショットバックアップでは、次の種類のファイルが生成されます。

SSTファイル: TiKV ノードがバックアップするデータを保存します。 SSTファイルのサイズは、リージョンのサイズと同じです。
backupmetaファイル: すべてのバックアップファイルの数、各バックアップファイルのキー範囲、サイズ、ハッシュ (sha256) 値など、バックアップタスクのメタデータを保存します。
backup.lockファイル: 複数のバックアップタスクが同じディレクトリにデータを保存することを防ぎます。

SST ファイルの命名形式

データが Google Cloud Storage (GCS) または 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 のカラムファミリーを示します ( cfがdefaultまたはwriteであるデータのみを復元します)。

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

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

SSTファイルの保存形式

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

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

データを GCS または 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

こちらも参照

TiDB スナップショットのバックアップおよび復元ガイド