-
Notifications
You must be signed in to change notification settings - Fork 657
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
TiDB Cloud Docs: Add documentation for new Recovery Group feature #17425
base: master
Are you sure you want to change the base?
TiDB Cloud Docs: Add documentation for new Recovery Group feature #17425
Conversation
This is a new feature that requires documentation to explain the core concepts to users. Signed-off-by: Ben Meadowcroft <ben.meadowcroft@pingcap.com>
|
||
- Recovery Group: a group of databases that are replicated between two clusters | ||
- Primary Cluster: the cluster where the database is actively written by the application | ||
- Secondary Cluster: the cluster where replicas of the database are located |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should remind users that we do not guarantee the readonly of replica databases on secondary, and users need to make ensure they won't write to replica databases on secondary.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Addressed in da21f75
|
||
7. Select which databases you wish to replicate as part of this recovery group. | ||
|
||
> **Note** |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should also remind user here
- we are not support replicate system tables to secondary cluster even users select All.
- we need to export a lot data from primary and import to secondary at backend during creation, which may have impact on online query for both primary and secondary cluster. Remind users to perform creation operation when traffic is low.
- All the selected databases in secondaries will be cleanup before replication establish for data consistency purpose, if the data matter, pls make backup before.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Addressed in da21f75
|
||
# Failover and Reprotect Databases | ||
|
||
Databases that are part of a replication group are replicated from one cluster to another (typucally in a different region of the cloud service provider). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
typo: typucally
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Addressed in da21f75
|
||
If the cluster that was impacted by the disaster is able to be brought online again, a replication relationship from the recovery region back to the original region can be established. This is performed using the **Reprotect** action. | ||
|
||
![Unprotected Recovery Group](/media/tidb-cloud/recovery-group/recovery-group-unprotected.png) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unprotected => Reprotected
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is the diagram from before the reprotect operation is performed (so the databases at this point are unprotected). The diagram later in this section is the diagram from after the reprotect operation is performed.
|
||
3. On the recovery group page, click the name of the recovery group that you wish to reprotect. | ||
|
||
> **Note** |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should also remind users
- we need to export a lot data from primary and import to secondary at backend during reprotecting, which may have impact on online query for both primary and secondary cluster. Remind users to perform creation operation when traffic is low.
- All the selected databases in secondaries will be cleanup before replication establish for data consistency purpose, if the data matter, pls make backup before.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Addressed in da21f75
|
||
This document describes how to create a Recovery Group to protect your databases running on TiDB Cloud Dedicated Clusters using the TiDB Cloud user interface. It also shows how to view details of the recovery group. | ||
|
||
## Prerequisites |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After Recovery Group is created, we will create account(in this pattern cloud-rg-*) in the secondary cluster, which will be used to replicated data into secondary cluster, we should remind user not to touch such account. If mistakenly delete such account, it will cause replication interrupted.
I not should where to put this remind message, just comment here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Addressed in da21f75
|
||
> **Note** | ||
> | ||
> Currently only one resiliency level is supported. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you add explanation for what does resiliency level means for the users? What is the expected behavior for the only supported resiliency level?
Signed-off-by: Ben Meadowcroft <ben.meadowcroft@pingcap.com>
Signed-off-by: Ben Meadowcroft <ben.meadowcroft@pingcap.com>
[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.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
@grovecai: adding LGTM is restricted to approvers and reviewers in OWNERS files. In response to this: Instructions 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/test-infra repository. |
After creating the recovery group, you might want to familiarize yourself with the failover and reprotect operations. These operations are used to **Failover** the primary cluster for the replicated databases from one cluster to the other, and then to later reestablish replication in the opposite direction to **Reprotect** the failed over databases. | ||
|
||
- [Failover Databases](/tidb-cloud/recovery-group-failover.md) | ||
- [Failover and Reprotect Databases](/tidb-cloud/recovery-group-failover.md) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As this docs is about Failover and Reprotect, do we need to remove "What's next" from this doc?
Co-authored-by: Grace Cai <qqzczy@126.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Rest LGTM
Co-authored-by: Grace Cai <qqzczy@126.com>
|
||
# Recovery Group Billing | ||
|
||
TiDB Cloud bills for recovery groups based on the deployed size of your TiKV nodes in the primary cluster of the recovery group. When you [create a recovery group](/tidb-cloud/recovery-group-get-started.md) for a cluster, you can select the primary cluster for the recovery group. The larger the TiKV configuration, the higher the cost for recovery group protection. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
pls add data processing part
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added in 4eb89d9
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should not tell the customer how we make the pricing of data processing - “This data processing cost includes the cross-region and cross-AZ traffic charges”, we just tell them there is a data processing cost charge by GB is enough.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, updated in 6bd256f
Signed-off-by: Ben Meadowcroft <ben.meadowcroft@pingcap.com>
Signed-off-by: Ben Meadowcroft <ben.meadowcroft@pingcap.com>
What is changed, added or deleted? (Required)
Recovery Groups are a new feature for TiDB Cloud, this PR contains initial documentation for this feature for review by the docs team.
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?