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 ノードから復元結果を受信します。
- RegionNotFoundまたはEpochNotMatch原因で一部のデータの復元に失敗した場合 (たとえば、TiKV ノードがダウンしている場合)、 BR は復元を再試行します。
- 復元に失敗し、再試行できないデータがある場合、復元タスクは失敗します。
- すべてのデータが復元されると、復元タスクは成功します。

バックアップファイル

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

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

SSTファイル: SSTノードがバックアップするデータを保存します。2 ファイルのサイズは、リージョンのサイズと同じです。
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 ファイル内のバックアップデータのエンコード形式の詳細については、テーブルデータからキー値へのマッピング参照してください。

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

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 スナップショットのバックアップと復元ガイド