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

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

アーキテクチャ

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

BR snapshot backup and restore architecture

バックアップのプロセス

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

snapshot backup process design

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

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パスにアップロードします。バックアップメタデータには、バックアップタイムスタンプ、テーブルと対応するバックアップファイル、データチェックサム、およびファイルチェックサムが含まれます。

復元のプロセス

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

snapshot restore process design

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

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

こちらもご覧ください

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