チェックポイントの復元

スナップショットの復元やログの復元は、ディスク枯渇やノードクラッシュなどの回復可能なエラーにより中断される可能性があります。TiDB v7.1.0より前のバージョンでは、エラーに対処した後でも中断前の復元の進行状況が無効になり、復元を最初からやり直す必要がありました。大規模クラスターでは、これはかなりの追加コストが発生します。

TiDB v7.1.0以降、バックアップ＆リストア（BR）にチェックポイント・リストア機能が導入され、中断されたリストアを再開できるようになりました。この機能により、中断されたリストアのリカバリ進行状況の大部分を保持できます。

アプリケーションシナリオ

TiDBクラスタが大規模で、障害発生後に再度リストアを行う余裕がない場合は、チェックポイントリストア機能を使用できます。brコマンドラインツール（以下、 br ）は、リストアされたシャードを定期的に記録します。これにより、次回のリストア再試行では、異常終了に近いリカバリ進捗ポイントを使用できます。

実施原則

チェックポイント復元の実装は、スナップショット復元とログ復元の2つの部分に分かれています。詳細については、 実装の詳細: チェックポイントデータを下流のクラスタに保存すると実装の詳細: チェックポイントデータを外部storageに保存する参照してください。

スナップショットの復元

スナップショット復元の実装はスナップショットバックアップと同様です。3 br 、キー範囲（リージョン）内のすべてのSSTファイルを一括して復元します。復元が完了すると、 brこの範囲と復元されたクラスタテーブルのテーブルIDを記録します。チェックポイント復元機能は、復元されたキー範囲を永続化するために、新しい復元情報を定期的に外部storageにアップロードします。

br復元を再試行する際、外部storageから復元されたキー範囲を読み取り、対応するテーブルIDと照合します。復元中、 brチェックポイント復元で記録されたキー範囲と重複し、同じテーブルIDを持つキー範囲をスキップします。

brリストアを再試行する前にテーブルを削除した場合、再試行時に新しく作成されたテーブルのテーブルIDは、以前にチェックポイントリストアに記録されたテーブルIDと異なります。この場合、 br以前のチェックポイントリストア情報をバイパスし、テーブルを再度リストアします。つまり、新しいIDを持つ同じテーブルは、古いIDのチェックポイントリストア情報を無視し、新しいIDに対応する新しいチェックポイントリストア情報を記録することになります。

MVCC (Multi-Version Concurrency Control) メカニズムを使用しているため、指定されたタイムスタンプを持つデータを順序なしで繰り返し書き込むことができます。

スナップショット復元を使用してデータベースまたはテーブルのDDLを復元する場合、パラメータifExistsが追加されます。既に作成済みとみなされる既存のデータベースまたはテーブルの場合、パラメータbrを指定すると復元は自動的にスキップされます。

ログの復元

ログリストアは、TiKVノードによってバックアップされたデータメタデータ（メタKV）をタイムスタンプ順に復元するプロセスです。チェックポイントリストアではまず、メタKVデータに基づいて、バックアップクラスタと復元されたクラスタ間の1対1のIDマッピング関係を確立します。これにより、メタKVのIDは複数回のリストア試行を通じて一貫性を保ち、メタKVを再度リストアできるようになります。

スナップショットバックアップファイルとは異なり、ログバックアップファイルの範囲は重複する可能性があります。そのため、キー範囲を復旧進捗メタデータとして直接使用することはできません。また、ログバックアップファイルの数が多すぎる場合もあります。ただし、各ログバックアップファイルは、ログバックアップメタデータ内で固定の位置を持ちます。つまり、ログバックアップメタデータ内の一意の位置を、復旧進捗メタデータとして各ログバックアップファイルに割り当てることができます。

ログバックアップメタデータには、ファイルメタデータの配列が含まれています。配列内の各ファイルメタデータは、複数のログバックアップファイルで構成されるファイルを表します。ファイルメタデータには、連結されたファイル内のログバックアップファイルのオフセットとサイズが記録されます。したがって、トリプル(log backup metadata name, file metadata array offset, log backup file array offset) brしてログバックアップファイルを一意に識別できます。

使用制限

チェックポイント復元はGCメカニズムに依存しており、復元されたすべてのデータを記録することはできません。詳細については、以下のセクションで説明します。

GCは一時停止されます

ログの復元中、復元されたデータの順序は不規則です。つまり、キーの削除レコードが書き込みレコードよりも先に復元される可能性があります。この時にGCがトリガーされると、キーのすべてのデータが削除され、GCはキーの後続の書き込みレコードを処理できなくなります。このような状況を回避するため、 brログの復元中にGCを一時停止します。3 br途中で終了した場合、GCは一時停止状態のままになります。

ログの復元が完了すると、GCは手動で起動することなく自動的に再起動されます。ただし、復元を続行しない場合は、以下の手順でGCを手動で有効にすることができます。

br GCを一時停止する原理は、 SET config tikv gc.ratio-threshold = -1.0実行してgc.ratio-threshold負の値に設定し、GCを一時停止することです。 gc.ratio-thresholdの値を変更することで、GCを手動で有効にすることができます。例えば、デフォルト値にリセットするには、 SET config tikv gc.ratio-threshold = 1.1実行します。

一部のデータは再度復元する必要があります

br復元を再試行する場合、復元中のデータやチェックポイントによって記録されていないデータなど、復元されたデータの一部を再度復元する必要がある場合があります。

• 中断の原因がエラーである場合、 br終了前に復元されたデータのメタ情報を保持します。この場合、次回の再試行では復元中のデータのみを再度復元する必要があります。

• brプロセスがシステムによって中断された場合、 br外部storageに復元されたデータのメタ情報を永続化できません。5 br 30秒ごとにメタ情報を永続化するため、中断前の30秒間に復元されたデータは永続化できず、次回の再試行時に再度復元する必要があります。

復元中にクラスタデータを変更しないようにする

リストアに失敗した後は、クラスタ内でのテーブルの書き込み、削除、または作成は避けてください。バックアップデータには、テーブル名変更のためのDDL操作が含まれている可能性があるためです。クラスタデータを変更すると、チェックポイントリストアでは、削除されたテーブルまたは既存のテーブルが外部操作によるものかどうかを判断できず、次回のリストア再試行の精度に影響します。

クロスメジャーバージョンのチェックポイントリカバリは推奨されません

メジャーバージョン間のチェックポイントリカバリは推奨されません。v8.5.0より前のLong-Term Support (LTS)バージョンを使用してbrリカバリが失敗したクラスターの場合、v8.5.0以降のLTSバージョンを使用してリカバリを続行することはできません。また、その逆も同様です。

実装の詳細: チェックポイントデータを下流のクラスタに保存する

注記：

v8.5.5以降、 BRはデフォルトでチェックポイントデータをダウンストリームクラスターに保存します。1パラメータを使用して--checkpoint-storageチェックポイントデータのstorageを指定できます。

チェックポイント復元操作は、スナップショット復元と PITR 復元の 2 つの部分に分かれています。

スナップショットの復元

初期復元中に、 brターゲットクラスタに__TiDB_BR_Temporary_Snapshot_Restore_Checkpointデータベースを作成します。このデータベースには、チェックポイントデータ、上流クラスタID、およびバックアップデータの BackupTS が記録されます。

復元が失敗した場合は、同じコマンドを使用して再試行できます。1 br __TiDB_BR_Temporary_Snapshot_Restore_Checkpointデータベースからチェックポイント情報を自動的に読み取り、最後の復元ポイントから再開します。

復元に失敗し、異なるチェックポイント情報を持つバックアップデータを同じクラスタに復元しようとすると、 brエラーを報告します。これは、現在の上流クラスタIDまたはBackupTSがチェックポイントレコードと異なることを示しています。復元クラスタがクリーンアップされている場合は、 __TiDB_BR_Temporary_Snapshot_Restore_Checkpointデータベースを手動で削除し、別のバックアップで再試行できます。

PITR復元

PITR（ポイントインタイムリカバリ）スナップショットの復元フェーズとログの復元フェーズで構成されます。

初期リストアでは、 brスナップショットリストアフェーズに入ります。BRは、チェックポイントデータ、上流クラスタID、バックアップデータのBackupTS（つまり、ログリストアの開始時点start-ts ）、およびログリストアの復元時点restored-ts __TiDB_BR_Temporary_Snapshot_Restore_Checkpointデータベースに記録します。このフェーズでリストアに失敗した場合、チェックポイントリストアを再開する際に、ログリストアのstart-tsとrestored-tsを調整することはできません。

初期復元中にログ復元フェーズに入ると、 brターゲットクラスターに__TiDB_BR_Temporary_Log_Restore_Checkpointデータベースを作成します。このデータベースには、チェックポイントデータ、アップストリームクラスターID、および復元時間範囲（ start-tsとrestored-ts ）が記録されます。このフェーズで復元に失敗した場合は、再試行時にチェックポイントデータベースに記録されているのと同じstart-tsとrestored-ts指定する必要があります。そうでない場合、 brエラーを報告し、現在指定されている復元時間範囲またはアップストリームクラスターIDがチェックポイントレコードと異なることを通知します。復元クラスターがクリーンアップされている場合は、 __TiDB_BR_Temporary_Log_Restore_Checkpointデータベースを手動で削除し、別のバックアップで再試行できます。

初期リストア中のログリストアフェーズに入る前に、 br restored-ts時点における上流および下流のクラスタデータベースとテーブルIDのマッピングを構築することに注意してください。このマッピングは、データベースIDとテーブルIDの重複割り当てを防ぐため、システムテーブルmysql.tidb_pitr_id_mapに保存されます。mysql.tidb_pitr_id_mapからデータを恣意的に削除するとmysql.tidb_pitr_id_map PITRリストアデータの不整合が発生する可能性があります。

注記：

以前のバージョンのクラスターとの互換性を確保するため、v8.5.5以降では、復元クラスターにシステムテーブルmysql.tidb_pitr_id_map存在しない場合、 pitr_id_mapデータがログバックアップディレクトリに書き込まれます。ファイル名はpitr_id_maps/pitr_id_map.cluster_id:{downstream-cluster-ID}.restored_ts:{restored-ts}です。

実装の詳細: チェックポイントデータを外部storageに保存する

注記：

v8.5.5以降、 BRはデフォルトでチェックポイントデータをダウンストリームクラスターに保存します。1パラメータを使用して--checkpoint-storageチェックポイントデータの外部storageを指定できます。例：

./br restore full -s "s3://backup-bucket/backup-prefix" --checkpoint-storage "s3://temp-bucket/checkpoints"

外部storageでは、チェックポイント データのディレクトリ構造は次のようになります。

• ルート パスrestore-{downstream-cluster-ID} 、ダウンストリーム クラスター ID {downstream-cluster-ID}を使用して、異なる復元クラスターを区別します。
• パスrestore-{downstream-cluster-ID}/logは、ログ復元フェーズ中にログ ファイルのチェックポイント データが保存されます。
• パスrestore-{downstream-cluster-ID}/sst 、ログ復元フェーズ中にログ バックアップによってバックアップされない SST ファイルのチェックポイント データが保存されます。
• パスrestore-{downstream-cluster-ID}/snapshotは、スナップショット復元フェーズ中にチェックポイント データが保存されます。

.
`-- restore-{downstream-cluster-ID}
    |-- log
    |   |-- checkpoint.meta
    |   |-- data
    |   |   |-- {uuid}.cpt
    |   |   |-- {uuid}.cpt
    |   |   `-- {uuid}.cpt
    |   |-- ingest_index.meta
    |   `-- progress.meta
    |-- snapshot
    |   |-- checkpoint.meta
    |   |-- checksum
    |   |   |-- {uuid}.cpt
    |   |   |-- {uuid}.cpt
    |   |   `-- {uuid}.cpt
    |   `-- data
    |       |-- {uuid}.cpt
    |       |-- {uuid}.cpt
    |       `-- {uuid}.cpt
    `-- sst
        `-- checkpoint.meta

チェックポイント復元操作は、スナップショット復元と PITR 復元の 2 つの部分に分かれています。

スナップショットの復元

初期復元中に、 br指定された外部storageにrestore-{downstream-cluster-ID}/snapshotパスbr作成します。このパスには、チェックポイントデータ、上流クラスタID、およびバックアップデータのBackupTSが記録されます。

復元が失敗した場合は、同じコマンドを使用して再試行できます。1 br 、指定された外部storageパスからチェックポイント情報を自動的に読み取り、最後の復元ポイントから再開します。

復元に失敗し、異なるチェックポイント情報を持つバックアップデータを同じクラスタに復元しようとすると、エラーコードbr報告されます。これは、現在の上流クラスタIDまたはBackupTSがチェックポイントレコードと異なることを示しています。復元クラスタがすでにクリーンアップされている場合は、外部storage内のチェックポイントデータを手動でクリーンアップするか、チェックポイントデータを保存する別の外部storageパスを指定して、別のバックアップで再試行してください。

PITR復元

PITR（ポイントインタイムリカバリ）スナップショットの復元フェーズとログの復元フェーズで構成されます。

初期リストアでは、 brスナップショットリストアフェーズに入ります。BRは、チェックポイントデータ、上流クラスタID、バックアップデータのBackupTS（つまり、ログリストアの開始時点start-ts ）、およびログリストアの復元時点restored-ts restore-{downstream-cluster-ID}/snapshotパスに記録します。このフェーズでリストアに失敗した場合、チェックポイントリストアを再開する際に、ログリストアのstart-tsとrestored-tsを調整することはできません。

初期復元中にログ復元フェーズに入ると、 br​​指定された外部storageにrestore-{downstream-cluster-ID}/logパスを作成します。このパスには、チェックポイント データ、アップストリーム クラスタ ID、および復元時間範囲 ( start-tsとrestored-ts ) が記録されます。このフェーズで復元が失敗した場合は、再試行時にチェックポイント データベースに記録されているのと同じstart-tsとrestored-ts指定する必要があります。そうでない場合、 brはエラーを報告し、現在指定されている復元時間範囲またはアップストリーム クラスタ ID がチェックポイント レコードと異なることを通知します。復元クラスタがクリーンアップされている場合は、外部storage内のチェックポイント データを手動でクリーンアップするか、チェックポイント データを保存するための別の外部storageパスを指定して、別のバックアップで再試行できます。

初期リストア中のログリストアフェーズに入る前に、 br restored-ts時点における上流クラスタと下流クラスタのデータベースIDとテーブルIDのマッピングを構築することに注意してください。このマッピングは、データベースIDとテーブルIDの重複割り当てを防ぐため、ファイル名pitr_id_maps/pitr_id_map.cluster_id:{downstream-cluster-ID}.restored_ts:{restored-ts}でチェックポイントstorageに保存されます。pitr_id_maps pitr_id_mapsからファイルを恣意的に削除すると、PITR リストアデータの不整合が発生する可能性があります。

注記：

以前のバージョンのクラスターとの互換性を確保するため、v8.5.5以降では、復元クラスターにシステムテーブルmysql.tidb_pitr_id_mapが存在せず、パラメータ--checkpoint-storageが指定されていない場合、 pitr_id_mapデータはログバックアップディレクトリに書き込まれます。ファイル名はpitr_id_maps/pitr_id_map.cluster_id:{downstream-cluster-ID}.restored_ts:{restored-ts}です。