From f25fa494ea4b0904203af74aa9265c5c2d2085ef Mon Sep 17 00:00:00 2001 From: Grace Cai Date: Sat, 4 Jul 2026 11:11:38 +0800 Subject: [PATCH 1/4] Create empty translation PR From 90ff4985700639a2a78e16a631fbae09903a8f68 Mon Sep 17 00:00:00 2001 From: "github-actions[bot]" Date: Sat, 4 Jul 2026 03:13:10 +0000 Subject: [PATCH 2/4] Auto-sync: Update English docs from Chinese PR Synced from: https://github.com/pingcap/docs-cn/pull/21711 Target PR: https://github.com/pingcap/docs/pull/23201 AI Provider: azure Co-authored-by: github-actions[bot] --- br/br-checkpoint-restore.md | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/br/br-checkpoint-restore.md b/br/br-checkpoint-restore.md index ca2ffed38bc4e..c329c0a3ee217 100644 --- a/br/br-checkpoint-restore.md +++ b/br/br-checkpoint-restore.md @@ -61,6 +61,18 @@ When `br` retries a restore, some data that has been restored might need to be r After a restore failure, avoid writing, deleting, or creating tables in the cluster. This is because the backup data might contain DDL operations for renaming tables. If you modify the cluster data, the checkpoint restore cannot decide whether the deleted or existing table are resulted from external operations, which affects the accuracy of the next restore retry. +> **Warning:** +> +> Starting from v8.5.5, if you delete a table being restored during the restore and then retry the restore from the checkpoint, you might encounter the following issues (see [#68709](https://github.com/pingcap/tidb/issues/68709) for details): +> +> - The restore is terminated due to a checksum verification failure. +> - The restored data is lost some time after the restore is completed. +> +> If you are sure that you want to abandon the current restore result, first perform one of the following operations based on the restore type, and then `DROP` the restored table: +> +> - For `restore point`, execute [`br abort`](/br/br-pitr-manual.md#中止恢复操作). +> - For `restore full`, manually delete the checkpoint database in the downstream cluster. The name format of the checkpoint database is `__TiDB_BR_Temporary_Snapshot_Restore_Checkpoint_`, where `` can be found in `mysql.tidb_restore_registry`. + ### Cross-major-version checkpoint recovery is not recommended Cross-major-version checkpoint recovery is not recommended. For clusters where `br` recovery fails using the Long-Term Support (LTS) versions prior to v8.5.0, recovery cannot be continued with v8.5.0 or later LTS versions, and vice versa. From a834b9a0559e1ac45d4fba0a31a48ff1b1628c81 Mon Sep 17 00:00:00 2001 From: Grace Cai Date: Sat, 4 Jul 2026 11:16:26 +0800 Subject: [PATCH 3/4] Update br/br-checkpoint-restore.md --- br/br-checkpoint-restore.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/br/br-checkpoint-restore.md b/br/br-checkpoint-restore.md index c329c0a3ee217..cd3fba7a8b98d 100644 --- a/br/br-checkpoint-restore.md +++ b/br/br-checkpoint-restore.md @@ -70,7 +70,7 @@ After a restore failure, avoid writing, deleting, or creating tables in the clus > > If you are sure that you want to abandon the current restore result, first perform one of the following operations based on the restore type, and then `DROP` the restored table: > -> - For `restore point`, execute [`br abort`](/br/br-pitr-manual.md#中止恢复操作). +> - For `restore point`, execute [`br abort`](/br/br-pitr-manual.md#abort-restore-operations). > - For `restore full`, manually delete the checkpoint database in the downstream cluster. The name format of the checkpoint database is `__TiDB_BR_Temporary_Snapshot_Restore_Checkpoint_`, where `` can be found in `mysql.tidb_restore_registry`. ### Cross-major-version checkpoint recovery is not recommended From f13c6ff904908dace3a6ec03d9ae1f9a9a8ac5a3 Mon Sep 17 00:00:00 2001 From: Grace Cai Date: Sat, 4 Jul 2026 18:12:15 +0800 Subject: [PATCH 4/4] Update br/br-checkpoint-restore.md Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com> --- br/br-checkpoint-restore.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/br/br-checkpoint-restore.md b/br/br-checkpoint-restore.md index cd3fba7a8b98d..596948422899c 100644 --- a/br/br-checkpoint-restore.md +++ b/br/br-checkpoint-restore.md @@ -63,15 +63,15 @@ After a restore failure, avoid writing, deleting, or creating tables in the clus > **Warning:** > -> Starting from v8.5.5, if you delete a table being restored during the restore and then retry the restore from the checkpoint, you might encounter the following issues (see [#68709](https://github.com/pingcap/tidb/issues/68709) for details): +> Starting from v8.5.5, if you delete a table during the restore process and then retry the restore from the checkpoint, you might encounter the following issues (see [#68709](https://github.com/pingcap/tidb/issues/68709) for details): > -> - The restore is terminated due to a checksum verification failure. -> - The restored data is lost some time after the restore is completed. +> - The restore terminates due to a checksum verification failure. +> - The restored data is lost some time after the restore completes. > > If you are sure that you want to abandon the current restore result, first perform one of the following operations based on the restore type, and then `DROP` the restored table: > > - For `restore point`, execute [`br abort`](/br/br-pitr-manual.md#abort-restore-operations). -> - For `restore full`, manually delete the checkpoint database in the downstream cluster. The name format of the checkpoint database is `__TiDB_BR_Temporary_Snapshot_Restore_Checkpoint_`, where `` can be found in `mysql.tidb_restore_registry`. +> - For `restore full`, manually delete the checkpoint database in the downstream cluster. The name format of the checkpoint database is `__TiDB_BR_Temporary_Snapshot_Restore_Checkpoint_`, where you can find `` in the `mysql.tidb_restore_registry` table. ### Cross-major-version checkpoint recovery is not recommended