br: support pitr filter and concurrent restore (#21835) #22201
Conversation
Signed-off-by: ti-chi-bot <ti-community-prow-bot@tidb.io>
ti-chi-bot
added
do-not-merge/hold
|
@lilin90 This PR has conflicts, I have hold it. |
|
@ti-chi-bot: ## If you want to know how to resolve it, please read the guide in TiDB Dev Guide. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the ti-community-infra/tichi repository. |
|
[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/L
Summary of ChangesHello @ti-chi-bot, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request significantly enhances the documentation for TiDB's Point-in-Time Recovery (PITR) features. It introduces comprehensive guides on how to leverage data filtering for selective restores, perform concurrent restore operations for improved efficiency, and navigate the complexities of compatibility between ongoing log backups and various restore types. Additionally, it provides crucial information on aborting failed restore tasks, ensuring users have the necessary tools and knowledge for robust data management. Highlights
🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console. Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
![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 documentation for PITR filter and concurrent restore features. The changes are well-written and provide useful information for users. I have a few minor suggestions to improve clarity and conciseness, mainly related to grammar and phrasing, in line with the documentation style guide.
| > - The regular expression in the restore task matches the table name at the `restored-ts` time point, with the following three possible cases: | ||
| > - Table A (table id = 1): the table name always matches the `--filter` regular expression at and before the `restored-ts` time point. In this case, PITR restores the table. | ||
| > - Table B (table id = 2): the table name does not match the `--filter` regular expression at some point before `restored-ts`, but matches at the `restored-ts` time point. In this case, PITR restores the table. | ||
| > - Table C (table id = 3): the table name matches the `--filter` regular expression at some point before `restored-ts`, but does **not** match at the `restored-ts` time point. In this case, PITR does **not** restore the table. |
There was a problem hiding this comment.
This explanation of how filters work with table renames is a bit verbose. For better readability, you can simplify it to focus on the core logic that the filter is evaluated against the table name at restored-ts.
| > - The regular expression in the restore task matches the table name at the `restored-ts` time point, with the following three possible cases: | |
| > - Table A (table id = 1): the table name always matches the `--filter` regular expression at and before the `restored-ts` time point. In this case, PITR restores the table. | |
| > - Table B (table id = 2): the table name does not match the `--filter` regular expression at some point before `restored-ts`, but matches at the `restored-ts` time point. In this case, PITR restores the table. | |
| > - Table C (table id = 3): the table name matches the `--filter` regular expression at some point before `restored-ts`, but does **not** match at the `restored-ts` time point. In this case, PITR does **not** restore the table. | |
| - The filter matches against the table name as it exists at the `restored-ts` timestamp. This means: | |
| - If a table's name matches the filter at `restored-ts`, PITR restores the table, even if its name did not match at an earlier time. | |
| - If a table's name does not match the filter at `restored-ts`, PITR does **not** restore the table, even if its name did match at an earlier time. |
| ### Compatibility between ongoing log backup and snapshot restore | ||
| Starting from v9.0.0, when a log backup task is running, if all of the following conditions are met, you can still perform snapshot restore (`br restore [full|database|table]`) and allow the restored data to be properly recorded by the ongoing log backup (hereinafter referred to as "log backup"): |
There was a problem hiding this comment.
The term 'log backup' is used consistently in this document. To improve readability, you can remove the parenthetical phrase '(hereinafter referred to as "log backup")'.
| Starting from v9.0.0, when a log backup task is running, if all of the following conditions are met, you can still perform snapshot restore (`br restore [full|database|table]`) and allow the restored data to be properly recorded by the ongoing log backup (hereinafter referred to as "log backup"): | |
| Starting from v9.0.0, when a log backup task is running, if all of the following conditions are met, you can still perform snapshot restore (`br restore [full|database|table]`) and allow the restored data to be properly recorded by the ongoing log backup: |
| #### Important limitation for PITR with ongoing log backup | ||
| When you perform the PITR operations while a log backup is running, the restored data will also be recorded in the ongoing log backup. However, due to the nature of log restore operations, data inconsistencies might occur within the restore window. The system writes metadata to external storage to mark both the time range and data range where consistency cannot be guaranteed. |
There was a problem hiding this comment.
For better readability, you can remove the definite article 'the' before 'PITR operations'.
| When you perform the PITR operations while a log backup is running, the restored data will also be recorded in the ongoing log backup. However, due to the nature of log restore operations, data inconsistencies might occur within the restore window. The system writes metadata to external storage to mark both the time range and data range where consistency cannot be guaranteed. | |
| When you perform PITR operations while a log backup is running, the restored data will also be recorded in the ongoing log backup. However, due to the nature of log restore operations, data inconsistencies might occur within the restore window. The system writes metadata to external storage to mark both the time range and data range where consistency cannot be guaranteed. |
| > | ||
| > The `abort` command only cleans up metadata. You need to manually delete any actual restored data from the cluster. | ||
| The examples of aborting restore operations using the same parameters as the original restore command are as follows: |
There was a problem hiding this comment.
For conciseness, you can rephrase this sentence to be more direct.
| The examples of aborting restore operations using the same parameters as the original restore command are as follows: | |
| Examples of aborting restore operations using the same parameters as the original restore command are as follows: |
|
@ti-chi-bot: The following test failed, say
Full PR test history. Your PR dashboard. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here. |
2 participants
This is an automated cherry-pick of #21835
What is changed, added or deleted? (Required)
Updates notes about PITR filter and concurrent restore.
Which TiDB version(s) do your changes apply to? (Required)
Tips for choosing the affected version(s):
By default, CHOOSE MASTER ONLY so your changes will be applied to the next TiDB major or minor releases. If your PR involves a product feature behavior change or a compatibility change, CHOOSE THE AFFECTED RELEASE BRANCH(ES) AND MASTER.
For details, see tips for choosing the affected versions (in Chinese).
What is the related PR or file link(s)?
Do your changes match any of the following descriptions?