forked from pingcap/docs
-
Notifications
You must be signed in to change notification settings - Fork 4
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
TiDB Cloud Docs: Add documentation for new Recovery Group feature (pi…
- Loading branch information
1 parent
218a5ab
commit 00dac2b
Showing
12 changed files
with
243 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,27 @@ | ||
| --- | ||
| title: Delete a Recovery Group | ||
| summary: Learn how to delete a Recovery Group when it is no longer needed. | ||
| --- | ||
|
|
||
| # Delete a Recovery Group | ||
|
|
||
| When a recovery group is no longer needed, you can delete it. | ||
|
|
||
| ## Delete a recovery group | ||
|
|
||
| When a recovery group is no longer needed to manage the replication of a set of databases, you can delete it from the system. | ||
|
|
||
| 1. In the [TiDB Cloud console](https://tidbcloud.com/), click <MDSvgIcon name="icon-left-projects" /> in the lower-left corner, switch to the target project if you have multiple projects, and then click **Project Settings**. | ||
|
|
||
| 2. In the **Project Settings** navigation pane, click **Recovery Group**. | ||
|
|
||
| 3. On the **Recovery Group** page, locate the name of the recovery group that you wish to delete. | ||
|
|
||
| 4. Click the **Action** menu for the recovery group, and then click **Delete**. The deletion dialog is displayed. | ||
|
|
||
| > **Warning** | ||
| > | ||
| > - Deleting a recovery group also removes all associated replication relationships associated with that recovery group. | ||
| > - The databases associated with the recovery group are no longer protected against disasters. | ||
| 5. Confirm that you understand the impact of the deletion by typing the name of the recovery group and clicking **I understand, delete it**. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,69 @@ | ||
| --- | ||
| title: Failover and Reprotect Databases | ||
| summary: Learn how to use a Recovery Group to failover and reprotect databases between TiDB Cloud clusters. | ||
| --- | ||
|
|
||
| # Failover and Reprotect Databases | ||
|
|
||
| Databases in a recovery group are replicated from one cluster to another, typically in a different region of the cloud service provider. | ||
|
|
||
| The **Failover** action promotes the replicated databases in the secondary region to be the new primary copy, ensuring ongoing availability during a regional outage. | ||
|
|
||
| When the regional outage is resolved, the ability to reverse the replication from the recovery region back to the original region is done using the **Reprotect** action. This ensures that the databases are protected against future disasters impacting their new region, and prepares them for migration back to the original region if desired. | ||
|
|
||
| ## Prerequisites | ||
|
|
||
| Before performing a failover, a recovery group should have been created and be successfully replicating to the secondary cluster. For more information, see [Get Started with Recovery Groups](/tidb-cloud/recovery-group-get-started.md). | ||
|
|
||
|  | ||
|
|
||
| ## Failover databases using a recovery group | ||
|
|
||
| In the event of a disaster, you can use the recovery group to failover databases to the secondary cluster. | ||
|
|
||
| 1. In the [TiDB Cloud console](https://tidbcloud.com/), click <MDSvgIcon name="icon-left-projects" /> in the lower-left corner, switch to the target project if you have multiple projects, and then click **Project Settings**. | ||
|
|
||
| 2. In the **Project Settings** navigation pane, click **Recovery Group**. | ||
|
|
||
| 3. On the **Recovery Group** page, locate the name of the recovery group that you wish to failover. | ||
|
|
||
| 4. Click the **Action** menu for the recovery group, and then click **Failover**. The failover dialog is displayed. | ||
|
|
||
| > **Warning** | ||
| > | ||
| > Performing a failover will sever the existing replication relationship. | ||
| 5. Select the secondary TiDB Cloud cluster to be promoted to the primary copy. Ensure that the selected cluster is in a healthy state. | ||
|
|
||
| 6. Confirm that you understand the potentially disruptive nature of a failover by typing **Failover** into the confirmation entry and clicking **I understand, failover group** to begin the failover. | ||
|
|
||
|  | ||
|
|
||
| ## Reprotect databases using a recovery group | ||
|
|
||
| After a failover completes, the replica databases on the secondary cluster are now the primary copy. However, these databases are unprotected against future disasters as the replication relationship is stopped by the failover process. | ||
|
|
||
| If the original primary cluster that was affected by the disaster can be brought online again, you can re-establish replication from the recovery region back to the original region using the **Reprotect** action. | ||
|
|
||
|  | ||
|
|
||
| 1. In the [TiDB Cloud console](https://tidbcloud.com/), click <MDSvgIcon name="icon-left-projects" /> in the lower-left corner, switch to the target project if you have multiple projects, and then click **Project Settings**. | ||
|
|
||
| 2. In the **Project Settings** navigation pane, click **Recovery Group**. | ||
|
|
||
| 3. On the **Recovery Group** page, locate the name of the recovery group that you wish to reprotect. | ||
|
|
||
| > **Note** | ||
| > | ||
| > The **Recovery Group Detail** page provides information about the recovery group, including current status and replication topology. | ||
| > During the reprotect synchronization, due to the volume of data transferred, the online query performance at the primary or secondary clusters might be affected. It is recommended that you schedule the reprotection of databases for a less busy period. | ||
| > **Warning** | ||
| > | ||
| > As part of the data replication necessary to perform the reprotect operation, the content of the selected databases will be replaced at the target cluster by the content of the databases from the (new) primary cluster. If you wish to preserve the unique content on the target cluster, complete a backup before performing the Reprotect operation. | ||
| 4. Click the **Action** menu for the recovery group, and then click **Reprotect**. The reprotect dialog is displayed. | ||
|
|
||
| 5. Confirm the reprotect operation by clicking **Reprotect** to begin the reprotect operation. | ||
|
|
||
|  |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,89 @@ | ||
| --- | ||
| title: Get Started with Recovery Groups | ||
| summary: Learn how to create a recovery group in TiDB Cloud and view its details. | ||
| --- | ||
|
|
||
| # Get Started with Recovery Groups | ||
|
|
||
| This document describes how to create a recovery group to protect your databases running on TiDB Cloud Dedicated clusters using the [TiDB Cloud console](https://tidbcloud.com/). It also shows how to view details of a recovery group. | ||
|
|
||
| ## Prerequisites | ||
|
|
||
| - A recovery group replicates your databases to another cluster to protect your databases from regional disasters. Before creating a recovery group, you need to have two TiDB Cloud Dedicated clusters. One cluster hosts the primary databases, and a second cluster hosts the replicas of the primary databases. If you have not done so already, follow the steps in [Create a TiDB Dedicated Cluster](/tidb-cloud/create-tidb-cluster.md) to create the necessary clusters. | ||
| - To create a recovery group, you must be in the `Organization Owner` role of your organization or the `Project Owner` role of the target project. | ||
|
|
||
| > **Note** | ||
| > | ||
| > Currently, only TiDB Dedicated clusters hosted on AWS support recovery groups. | ||
| ## Create a new recovery group | ||
|
|
||
| To create a recovery group, perform the following steps: | ||
|
|
||
| 1. In the [TiDB Cloud console](https://tidbcloud.com/), click <MDSvgIcon name="icon-left-projects" /> in the lower-left corner, switch to the target project if you have multiple projects, and then click **Project Settings**. | ||
|
|
||
| 2. In the **Project Settings** navigation pane, click **Recovery Group**. | ||
|
|
||
| 3. On the **Recovery Group** page, click **Create Recovery Group**. | ||
|
|
||
| 4. On the **Create Recovery Group** page, enter a name for the recovery group. | ||
|
|
||
| > **Note** | ||
| > | ||
| > Currently only one resiliency level is supported. For more information, see [About resiliency levels](#about-resiliency-levels). | ||
| 5. Select the TiDB Dedicated cluster that will be the primary cluster for this group. | ||
|
|
||
| 6. Select the TiDB Dedicated cluster that will be the secondary cluster where databases will be replicated for this group. | ||
|
|
||
| 7. Select which databases you wish to replicate as part of this recovery group. | ||
|
|
||
| > **Note** | ||
| > | ||
| > When assigning databases to the group, you can select specific databases, or select all (non-system) databases on the primary cluster (current and future). | ||
| > | ||
| > - If you **Assign all databases (current and future)**, any future databases added to the cluster will be automatically included in this recovery group and replicated to the secondary cluster. | ||
| > - If you **Assign specific databases**, select the specific databases on the primary cluster that you want to replicate to the secondary cluster. If any databases are added to the primary cluster in the future, these new databases will not be automatically replicated as part of this recovery group. | ||
| > | ||
| > During the initial replication, due to the volume of data transferred, the online query performance at the primary or secondary clusters might be affected. Schedule the initial protection of databases for a less busy period. | ||
| > **Warning** | ||
| > | ||
| > During the initial replication, the content of the selected databases at the primary cluster will replace the content of the databases at the secondary cluster. If you wish to preserve the unique content at the secondary cluster, complete a backup before setting up the recovery group. | ||
| 8. Review the summary information, and then click **Create** to begin protecting the databases as part of the new recovery group. | ||
|
|
||
| ## View recovery group details | ||
|
|
||
| After creating a recovery group, you can view its status information on the **Recovery Group Detail** page: | ||
|
|
||
| 1. In the [TiDB Cloud console](https://tidbcloud.com/), click <MDSvgIcon name="icon-left-projects" /> in the lower-left corner, switch to the target project if you have multiple projects, and then click **Project Settings**. | ||
|
|
||
| 2. In the **Project Settings** navigation pane, click **Recovery Group**. | ||
|
|
||
| 3. On the **Recovery Group** page, click the name of the recovery group that you wish to view. | ||
|
|
||
| The **Recovery Group Detail** page provides information about a recovery group, including its configuration details, status, and metrics on the replication throughput and latency. | ||
|
|
||
| 4. When a replication relationship is fully established and functioning, the status is displayed as **Available**. | ||
|
|
||
| > **Warning** | ||
| > | ||
| > During the setup of a recovery group, an account named following the pattern `cloud-rg-*` will be created on the secondary cluster for the replication process. Deleting or modifying this account will interrupt the replication. | ||
| ## About resiliency levels | ||
|
|
||
| A resiliency level defines the consistency characteristics of data reading in different scenarios of a recovery group. Currently, TiDB Cloud only provides the following resiliency level: | ||
|
|
||
| - No consistency guaranteed. During the replication of a recovery group, the downstream cluster does not guarantee transaction consistency read. When the upstream cluster becomes unavailable, you can not restore the data in the downstream cluster to a transaction consistency state. | ||
|
|
||
| TiDB Cloud will provide two additional resiliency levels in the near future: | ||
|
|
||
| - Eventual consistency. During the replication of a recovery group, the downstream cluster does not guarantee transaction consistency read. However, when the upstream cluster becomes unavailable, you can restore the data in the downstream cluster to a transaction consistency state. | ||
| - Near real-time consistency. During the replication of a recovery group, the downstream cluster provides approximately real-time transaction consistency read. When the upstream cluster becomes unavailable, you can restore the data in the downstream cluster to a transaction consistency state. | ||
|
|
||
| ## What's next | ||
|
|
||
| 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 re-establish replication in the opposite direction to **Reprotect** the failed over databases. | ||
|
|
||
| - [Failover and Reprotect Databases](/tidb-cloud/recovery-group-failover.md) |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,37 @@ | ||
| --- | ||
| title: Recovery Group Overview (Beta) | ||
| summary: Learn how to protect your databases against disasters by using TiDB Cloud recovery groups. | ||
| --- | ||
|
|
||
| # Recovery Group Overview (Beta) | ||
|
|
||
| A TiDB Cloud recovery group allows you to replicate your databases between TiDB Cloud Dedicated clusters for protection against regional disasters. You can orchestrate the failover of databases from one cluster to another. After a failover to the secondary cluster, if the original primary cluster becomes available again, you can re-establish replication in the reverse direction to reprotect your databases. | ||
|
|
||
| ## Architecture | ||
|
|
||
| A recovery group consists of a set of replicated databases that can be failed over together between two TiDB Dedicated clusters. Each recovery group is assigned a primary cluster, and databases on this primary cluster are associated with the group and are then replicated to the secondary cluster. | ||
|
|
||
|  | ||
|
|
||
| - 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 | ||
|
|
||
| > **Note** | ||
| > | ||
| > Client connections to the replica databases are not explicitly forced to be read-only by the Recovery Group feature. Ensuring that the application connecting to the replica databases only performs read-only queries is the responsibility of the application. | ||
| ## Key features and limitations | ||
|
|
||
| - Currently, only TiDB Dedicated clusters hosted on AWS support recovery groups. | ||
| - Recovery groups are established between two clusters. | ||
| - Bi-directional replication of a database is not supported with recovery groups. | ||
|
|
||
| > **Warning** | ||
| > | ||
| > This feature is in beta and not recommended for production environments. | ||
| ## What's next | ||
|
|
||
| - To get started with recovery groups, see [Create Database Recovery Group](/tidb-cloud/recovery-group-get-started.md). | ||
| - To learn how to use a recovery group, see [Failover and Reprotect Databases](/tidb-cloud/recovery-group-failover.md). |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,14 @@ | ||
| --- | ||
| title: Recovery Group Billing | ||
| summary: Learn about billing for recovery groups in TiDB Cloud. | ||
| --- | ||
|
|
||
| # 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. | ||
|
|
||
| TiDB Cloud also bills for data processing per GiB basis. The data processing price varies depending on whether the data is replicated to a secondary cluster in another region, or within the same region. | ||
|
|
||
| ## Pricing | ||
|
|
||
| To learn about the supported regions and the pricing for TiDB Cloud recovery groups, see [Recovery Group Cost](https://www.pingcap.com/tidb-cloud-pricing-details/#recovery-group-cost). |