チェックポイントバックアップ

スナップショットバックアップは、ディスクの枯渇やノードのクラッシュなどの回復可能なエラーにより中断される場合があります。 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を定期的に更新します。 br終了すると、 gc-safepoint更新が間に合わなくなります。その結果、次のバックアップの再試行前に、データがガベージコレクションされる可能性があります。

この状況を回避するために、 gcttlが指定されていない場合、 brデフォルトでgc-safepointを約 1 時間保持します。必要に応じて、 gcttlパラメータを設定して保存期間を延長できます。

次の例では、保持期間gc-safepointを延長するためにgcttl ～ 15 時間 (54000 秒) を設定します。

br backup full \
--storage local:///br_data/ --pd "${PD_IP}:2379" \
--gcttl 54000

注記：
バックアップ前に作成されたgc-safepointスナップショットバックアップの完了後に削除されます。手動で削除する必要はありません。

一部のデータは再度バックアップする必要があります

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

中断がエラーによって引き起こされた場合、 brは終了前にバックアップされたデータのメタ情報を永続化します。この場合、次回の再試行では、バックアップ中のデータのみを再度バックアップする必要があります。
brプロセスがシステムによって中断されると、 br外部storageにバックアップされたデータのメタ情報を永続化できなくなります。 br 30 秒ごとにメタ情報を永続化するため、中断前の最後の 30 秒間にバックアップされたデータは永続化できないため、次の再試行時に再度バックアップする必要があります。