TiDB Cloud
TiDB Self-Managed
Learning Center
お問い合わせ

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

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

アーキテクチャ

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

BR snapshot backup and restore architecture

バックアップのプロセス

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

snapshot backup process design

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

  1. BRはbr backup fullコマンドを受信します。

    • バックアップの時点とstorageパスを取得します。

  2. BR はバックアップ データをスケジュールします。

    • GC を一時停止: BR は、バックアップ データがTiDB GC メカニズムでクリーンアップされるのを防ぐために TiDB GC 時間を設定します。
    • TiKV およびリージョン情報を取得する: BR はPD にアクセスして、すべての TiKV ノードのアドレスとリージョンのデータ分布を取得します。
    • TiKV にデータのバックアップを要求します。BRはバックアップ要求を作成し、すべての TiKV ノードに送信します。バックアップ要求には、バックアップの時点、バックアップするリージョン、およびstorageパスが含まれます。

  3. TiKV はバックアップ要求を受け入れ、バックアップ ワーカーを開始します。

  4. TiKV はデータをバックアップします。

    • KV のスキャン: バックアップ ワーカーは、リーダーが配置されているリージョンからバックアップ時点に対応するデータを読み取ります。
    • SST の生成: バックアップ ワーカーはデータを SST ファイルに保存し、メモリに格納します。
    • SST のアップロード: バックアップ ワーカーは SST ファイルをstorageパスにアップロードします。

  5. BR は各 TiKV ノードからバックアップ結果を受信します。

    • リージョンの変更 (たとえば、TiKV ノードがダウンしている) により一部のデータのバックアップに失敗した場合、 BR はバックアップを再試行します。
    • バックアップに失敗し、再試行できないデータがある場合、バックアップ タスクは失敗します。
    • すべてのデータがバックアップされた後、 BR はメタデータをバックアップします。

  6. BR はメタデータをバックアップします。

    • スキーマのバックアップ: BR はテーブル スキーマをバックアップし、テーブル データのチェックサムを計算します。
    • メタデータのアップロード: BR はバックアップ メタデータを生成し、storageパスにアップロードします。バックアップ メタデータには、バックアップのタイムスタンプ、テーブルと対応するバックアップ ファイル、データ チェックサム、およびファイル チェックサムが含まれます。

復元のプロセス

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

snapshot restore process design

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

  1. BRはbr restoreコマンドを受信します。

    • データstorageパスと復元するデータベースまたはテーブルを取得します。
    • 復元するテーブルが存在するかどうか、また復元の要件を満たしているかどうかを確認します。

  2. BR はデータの復元をスケジュールします。

    • リージョンスケジュールの一時停止: BR は、復元中に自動リージョンスケジュールを一時停止するように PD に要求します。
    • スキーマの復元: BR は、バックアップ データのスキーマと、復元するデータベースおよびテーブルを取得します。新しく作成されたテーブルの ID は、バックアップ データの ID と異なる場合があることに注意してください。
    • リージョンの分割と分散: BR は、バックアップ データに基づいて PD にリージョンの割り当て (リージョンの分割) を要求し、リージョンがstorageノードに均等に分散されるようにスケジュールします (リージョンの分散)。各リージョンには、指定されたデータ範囲[start key, end key)があります。
    • TiKV にデータの復元を要求する: BR は、リージョン分割の結果に応じて復元要求を作成し、対応する TiKV ノードに送信します。復元要求には、復元するデータと書き換えルールが含まれます。

  3. TiKV は復元要求を受け入れ、復元ワーカーを開始します。

    • 復元ワーカーは、復元するために読み取る必要があるバックアップ データを計算します。

  4. TiKV はデータを復元します。

    • SST のダウンロード: 復元ワーカーは、対応する SST ファイルをstorageパスからローカル ディレクトリにダウンロードします。
    • KV の書き換え: リストア ワーカーは新しいテーブル ID に従って KV データを書き換えます。つまり、 キーバリューの元のテーブル ID を新しいテーブル ID に置き換えます。リストア ワーカーは、同じ方法でインデックス ID も書き換えます。
    • SSTの取り込み: 復元ワーカーは処理された SST ファイルを RocksDB に取り込みます。
    • 復元結果の報告: 復元ワーカーは復元結果をBRに報告します。

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

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

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

参照

このページは役に立ちましたか？