docs: add checkpoint restore warning#23201
Conversation
qiancai
added
needs-cherry-pick-release-8.5
|
Note Gemini is unable to generate a review for this pull request due to the file types involved not being currently supported. |
ti-chi-bot
Bot
added
the
size/XS
Synced from: pingcap/docs-cn#21711 Target PR: pingcap#23201 AI Provider: azure Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
|
Auto-sync completed successfully Source PR: pingcap/docs-cn#21711 English documentation has been updated based on Chinese documentation changes. |
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
ti-chi-bot
Bot
added
size/S
|
/gemini review |
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request adds a warning section to the br-checkpoint-restore.md documentation, detailing the risks of deleting a table during an active restore and retrying from a checkpoint starting from v8.5.5. It outlines potential issues, such as checksum failures and data loss, and provides instructions on how to properly abandon the restore. The reviewer suggested refining the warning block to improve clarity, eliminate repetitive phrasing, and adhere to the style guide by using active voice and the second person.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
| > **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#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_<restoreID>`, where `<restoreID>` can be found in `mysql.tidb_restore_registry`. |
There was a problem hiding this comment.
To improve clarity, reduce repetition, and adhere to the active voice and second-person guidelines in the style guide, we can refine this warning block:
- Avoid repeating "restored" and "restore" in "delete a table being restored during the restore".
- Change passive voice ("is terminated", "is completed", "can be found") to active voice ("terminates", "completes", "you can find").
- Use second person ("you") to address the user directly.
| > **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#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_<restoreID>`, where `<restoreID>` can be found in `mysql.tidb_restore_registry`. | |
| > **Warning:** | |
| > | |
| > 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 terminates due to a checksum verification failure. | |
| > - You might lose the restored data 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_<restoreID>`, where you can find `<restoreID>` in the `mysql.tidb_restore_registry` table. |
1 participant
First-time contributors' checklist
What is changed, added or deleted? (Required)
Add a warning for checkpoint restore after DROP TABLE, covering checksum failure or possible later data loss, and link to the related issue.
Which TiDB version(s) do your changes apply to? (Required)
What is the related PR or file link(s)?
Do your changes match any of the following descriptions?