TiDB スナップショットのバックアップと復元のアーキテクチャ
このドキュメントでは、バックアップと復元 ( BR ) ツールを例として使用して、TiDB スナップショットのバックアップと復元のアーキテクチャとプロセスを紹介します。
アーキテクチャ
TiDB スナップショットのバックアップと復元のアーキテクチャは次のとおりです。
バックアップのプロセス
クラスタ スナップショット バックアップのプロセスは次のとおりです。
完全なバックアップ プロセスは次のとおりです。
BR は
br backup full
コマンドを受信します。- バックアップ時点とstorageパスを取得します。
BR はバックアップ データをスケジュールします。
- Pause GC : BR は、 TiDB GC 時間を構成して、バックアップ データがTiDB GC メカニズムクリーンアップされるのを防ぎます。
- Fetch TiKV and リージョン info : BR はPD にアクセスして、すべての TiKV ノード アドレスとリージョンのデータ分布を取得します。
- データのバックアップを TiKV に要求する: BR はバックアップ要求を作成し、それをすべての TiKV ノードに送信します。バックアップ要求には、バックアップ時点、バックアップするリージョン、およびstorageパスが含まれます。
TiKV はバックアップ リクエストを受け入れ、バックアップ ワーカーを開始します。
TiKV がデータをバックアップします。
- Scan KVs : バックアップ ワーカーは、リーダーが配置されているリージョンからバックアップ時点に対応するデータを読み取ります。
- Generate SST : バックアップ ワーカーはデータを SST ファイルに保存し、メモリに保存します。
- Upload SST : バックアップ ワーカーが SST ファイルをstorageパスにアップロードします。
BR は、各 TiKV ノードからバックアップ結果を受け取ります。
- たとえば、TiKV ノードがダウンしているなど、リージョンの変更が原因で一部のデータのバックアップに失敗した場合、 BR はバックアップを再試行します。
- バックアップに失敗し、再試行できないデータがある場合、バックアップ タスクは失敗します。
- すべてのデータがバックアップされた後、 BR はメタデータをバックアップします。
BR はメタデータをバックアップします。
- スキーマのバックアップ: BR はテーブル スキーマをバックアップし、テーブル データのチェックサムを計算します。
- メタデータのアップロード: BR はバックアップ メタデータを生成し、それをstorageパスにアップロードします。バックアップ メタデータには、バックアップ タイムスタンプ、テーブルと対応するバックアップ ファイル、データ チェックサム、およびファイル チェックサムが含まれます。
復元のプロセス
クラスター スナップショットの復元のプロセスは次のとおりです。
完全な復元プロセスは次のとおりです。
BR は
br restore
コマンドを受信します。- 復元するデータstorageパスとデータベースまたはテーブルを取得します。
- 復元するテーブルが存在するかどうか、および復元の要件を満たしているかどうかを確認します。
BR は復元データをスケジュールします。
- リージョンスケジュールの一時停止: BR はPD に、復元中に自動リージョンスケジューリングを一時停止するよう要求します。
- Restore schema : BR は、バックアップ データのスキーマと、復元するデータベースとテーブルを取得します。新しく作成されたテーブルの ID は、バックアップ データの ID とは異なる場合があることに注意してください。
- Split & scatter リージョン : BR は、バックアップ データに基づいてリージョンを割り当てるように PD に要求し (split リージョン)、リージョンがstorageノードに均等に分散されるようにスケジュールします (scatter リージョン)。各リージョンには指定されたデータ範囲があります
[start key, end key)
。 - TiKV にデータの復元をリクエストする: BR は復元リクエストを作成し、リージョン分割の結果に従って、対応する TiKV ノードに送信します。復元要求には、復元するデータと書き換え規則が含まれます。
TiKV は復元要求を受け入れ、復元ワーカーを開始します。
- 復元ワーカーは、復元するために読み取る必要があるバックアップ データを計算します。
TiKV がデータを復元します。
- Download SST : 復元ワーカーは、対応する SST ファイルをstorageパスからローカル ディレクトリにダウンロードします。
- Rewrite KVs : 復元ワーカーは、新しいテーブル ID に従って KV データを書き換えます。つまり、 キー値の元のテーブル ID を新しいテーブル ID に置き換えます。復元ワーカーも同様にインデックス ID を書き換えます。
- 取り込み SST : 復元ワーカーは、処理された SST ファイルを RocksDB に取り込みます。
- 復元結果の報告: 復元ワーカーは復元結果をBRに報告します。
BR は、各 TiKV ノードから復元結果を受け取ります。
RegionNotFound
またはEpochNotMatch
が原因で一部のデータの復元に失敗した場合 (たとえば、TiKV ノードがダウンしている場合)、 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