チェックポイントバックアップ
スナップショットバックアップは、ディスク枯渇やノードクラッシュなどの回復可能なエラーにより中断される可能性があります。TiDB v6.5.0より前のバージョンでは、中断前にバックアップされたデータはエラーが解決された後でも無効となり、最初からバックアップをやり直す必要がありました。大規模クラスターの場合、これはかなりのコスト増加につながります。
TiDB v6.5.0では、バックアップとリストア（BR）にチェックポイント・バックアップ機能が導入され、中断されたバックアップを続行できるようになりました。この機能により、中断されたバックアップのほとんどのデータを保持できます。
アプリケーションシナリオ
TiDBクラスタが大規模で、障害発生後に再度バックアップを行う余裕がない場合は、チェックポイントバックアップ機能を使用できます。brコマンドラインツール（以下、 br ）は、バックアップ済みのシャードを定期的に記録します。これにより、次回のバックアップ再試行では、異常終了時のバックアップの進捗状況を使用できます。
実装の詳細
スナップショットバックアップ中、 brテーブルを対応するキー空間にエンコードし、バックアップRPCリクエストを生成してTiKVノードに送信します。バックアップリクエストを受信すると、TiKVノードは要求された範囲内のデータをバックアップします。TiKVノードは、リージョンのデータのバックアップを完了するたびに、この範囲のバックアップ情報をbrに返します。
br TiKV ノードから返された情報を記録し、 brバックアップされたキー範囲を取得するのに役立ちます。チェックポイント・バックアップ機能は、定期的に新しいバックアップ情報を外部storageにアップロードし、バックアップされたキー範囲を永続化します。
brバックアップを再試行する際、外部storageからバックアップ済みのキー範囲を読み取り、バックアップタスクのキー範囲と比較します。この差分データは、 brチェックポイントバックアップでまだバックアップする必要があるキー範囲を特定するのに役立ちます。
使用制限
チェックポイント・バックアップはGCメカニズムに依存しており、バックアップされたすべてのデータを復元することはできません。詳細については、以下のセクションで説明します。
バックアップの再試行はGCの前に行う必要があります
バックアップ中、 br PD内のバックアップスナップショットgc-safepointを定期的に更新し、データのガベージコレクションを回避します。5 br終了すると、 gc-safepoint時間内に更新されません。その結果、次のバックアップ再試行までに、データがガベージコレクションされている可能性があります。
このような状況を回避するため、 gcttl指定されていない場合、 brデフォルトでgc-safepoint約1時間保持します。必要に応じて、 gcttlパラメータを設定することで保持期間を延長できます。
次の例では、 gcttl 15 時間 (54000 秒) に設定して、保持期間gc-safepointを延長します。
tiup br backup full \
--storage local:///br_data/ --pd "${PD_IP}:2379" \
--gcttl 54000
注記：
スナップショットバックアップが完了すると、バックアップ前に作成された
gc-safepointは削除されます。手動で削除する必要はありません。
一部のデータは再度バックアップする必要があります
brバックアップを再試行する場合、バックアップ中のデータやチェックポイントで記録されていないデータなど、バックアップ済みのデータの一部を再度バックアップする必要がある場合があります。
中断の原因がエラーである場合、
br終了前にバックアップされたデータのメタ情報を保持します。この場合、次回の再試行では、バックアップ中のデータのみを再度バックアップする必要があります。brプロセスがシステムによって中断された場合、br外部storageにバックアップされたデータのメタ情報を永続化できません。5br30秒ごとにメタ情報を永続化するため、中断前の30秒間にバックアップされたデータは永続化できず、次回の再試行時に再度バックアップする必要があります。