From a071f317a6eed0492db5cd1318cf7169f448adfd Mon Sep 17 00:00:00 2001 From: Cheng Weiwei <65707268+wildpcww@users.noreply.github.com> Date: Mon, 24 Aug 2026 12:09:54 +0800 Subject: [PATCH 01/20] Single AZ support --- tidb-cloud/architecture-concepts.md | 2 ++ tidb-cloud/byoc/byoc-initialize-service.md | 4 ++-- tidb-cloud/byoc/byoc-prepare-environment-aws.md | 6 +++--- tidb-cloud/byoc/create-resource-pool-byoc.md | 17 ++++++++++++----- tidb-cloud/byoc/create-tidb-instance-byoc.md | 2 +- tidb-cloud/byoc/manage-resource-pools-byoc.md | 1 + tidb-cloud/byoc/multi-region-deployment.md | 2 +- .../premium/backup-and-restore-premium.md | 4 ++-- 8 files changed, 24 insertions(+), 14 deletions(-) diff --git a/tidb-cloud/architecture-concepts.md b/tidb-cloud/architecture-concepts.md index 763828faf26c3..81fefae04d5ce 100644 --- a/tidb-cloud/architecture-concepts.md +++ b/tidb-cloud/architecture-concepts.md @@ -104,6 +104,8 @@ BYOC provides the following features: To meet different workload requirements, TiDB Cloud BYOC supports both Single-AZ and Multi-AZ deployments, enabling you to choose between lower-latency zonal deployment and higher-resilience deployment across multiple availability zones. +High availability is configured for each resource pool. A Zonal resource pool is deployed in a single availability zone, while a Regional resource pool is deployed across multiple availability zones. TiDB Cloud determines the availability zone placement based on the BYOC region configuration and available cloud resources. Instances created or restored in a resource pool inherit its high availability mode. After a resource pool is created, you cannot change its high availability mode or availability zone placement. + ![TiDB Cloud BYOC Architecture](/media/tidb-cloud/byoc-architecture.png) A TiDB Cloud BYOC deployment includes the following major components: diff --git a/tidb-cloud/byoc/byoc-initialize-service.md b/tidb-cloud/byoc/byoc-initialize-service.md index e2b5fa8f01f4e..7348810a9c3e6 100644 --- a/tidb-cloud/byoc/byoc-initialize-service.md +++ b/tidb-cloud/byoc/byoc-initialize-service.md @@ -11,7 +11,7 @@ After deploying your BYOC infrastructure, create a resource pool, create your fi You can now provision resource pools and TiDB instances directly via the TiDB Cloud console. -1. Create a resource pool. Log in to the [TiDB Cloud console](https://tidbcloud.com/) and follow the instructions in [Create a Resource Pool](/tidb-cloud/byoc/create-resource-pool-byoc.md) to create a resource pool in the target cloud provider and region. +1. Create a resource pool. Log in to the [TiDB Cloud console](https://tidbcloud.com/) and follow the instructions in [Create a Resource Pool](/tidb-cloud/byoc/create-resource-pool-byoc.md) to create a resource pool in the target cloud provider and region. When creating the resource pool, select Zonal or Regional high availability based on your workload requirements. Instances created or restored in the resource pool inherit its high availability mode. 2. After the resource pool becomes **Active**, follow the instructions in [Create a {{{ .byoc }}} Instance](/tidb-cloud/byoc/create-tidb-instance-byoc.md) to create a new instance in the resource pool. @@ -34,7 +34,7 @@ After preparing your backup file in Amazon S3, you can restore the data to a new Once the access keys are configured, you can initiate the restore job from the TiDB Cloud console. - During restore, select an active resource pool in the target cloud provider and region. + During restore, select an active resource pool in the target cloud provider and region. The restored instance inherits the high availability mode of the selected resource pool. For step-by-step restoration procedures, see [Restore backups from cloud storage](/tidb-cloud/premium/backup-and-restore-premium.md#restore-backups-from-cloud-storage). diff --git a/tidb-cloud/byoc/byoc-prepare-environment-aws.md b/tidb-cloud/byoc/byoc-prepare-environment-aws.md index eb18dfcec3ac0..803813775df5b 100644 --- a/tidb-cloud/byoc/byoc-prepare-environment-aws.md +++ b/tidb-cloud/byoc/byoc-prepare-environment-aws.md @@ -37,9 +37,9 @@ TiDB is a distributed database that requires specific infrastructure for high av - **Option B: POC / Cost Optimization (Single-AZ).** Select exactly **1 AZ**. For example, `us-west-2a`. - > **Note:** - > - > Multi-AZ deployment functionality is disabled for this configuration. +The availability zones prepared for the BYOC region determine where TiDB Cloud can place resource pools. When creating a resource pool, you select either Zonal or Regional high availability. A Zonal resource pool is placed in one availability zone. A Regional resource pool requires at least three eligible availability zones in the region. + +If the BYOC region is initially prepared with a single availability zone, TiDB Cloud uses that availability zone for Zonal resource pools. You can create a Regional resource pool only when two additional eligible availability zones are available. If you plan to use Regional resource pools, confirm during environment preparation that the region can provide at least three eligible availability zones. ## Step 4. Create a hosted zone for TiDB diff --git a/tidb-cloud/byoc/create-resource-pool-byoc.md b/tidb-cloud/byoc/create-resource-pool-byoc.md index c7f90b91b53aa..e38ed78a754d1 100644 --- a/tidb-cloud/byoc/create-resource-pool-byoc.md +++ b/tidb-cloud/byoc/create-resource-pool-byoc.md @@ -48,7 +48,18 @@ To create a resource pool, take the following steps: If you set a Pool vCPU Limit, make sure that the total vCPUs of the initial TiKV and TiFlash resources do not exceed 50% of the Pool vCPU Limit. This helps reserve capacity for future instance creation and automatic scale-out. -6. In the **Pool CIDR** area, review or enter the CIDR range for the resource pool. +6. In the **High Availability** area, select a high availability mode for the resource pool. + + - **Zonal**: deploys the resource pool in a single availability zone for lower network latency. + - **Regional**: deploys the resource pool across multiple availability zones for higher availability and resilience against an availability-zone-level outage. + + You must select a high availability mode before creating the resource pool. You cannot select the specific availability zones. TiDB Cloud determines the availability zones based on the BYOC region configuration and available cloud resources. + + To create a Regional resource pool, at least three eligible availability zones must be available in the region. If this requirement is not met, you cannot create the Regional resource pool. + + After the resource pool is created, you cannot change its high availability mode or availability zone placement. + +7. In the **Pool CIDR** area, review or enter the CIDR range for the resource pool. The resource pool CIDR is used as the network address range for resources in the resource pool and cannot be modified after the resource pool is created. @@ -61,10 +72,6 @@ To create a resource pool, take the following steps: TiDB Cloud validates CIDR overlap with known TiDB Cloud managed network ranges in the target region. TiDB Cloud cannot detect overlap with your application VPCs, on-premises networks, or VPN networks. You must verify these customer-managed network ranges before creating the resource pool. -7. In the **High Availability** area, review the high availability mode. - - The high availability mode is inherited from the BYOC deployment configuration of the selected region. You cannot change it when creating a Resource Pool. - 8. (Optional) In the **AWS Resource Tags** area, add tags. Tags are applied to all taggable AWS resources within the resource pool. diff --git a/tidb-cloud/byoc/create-tidb-instance-byoc.md b/tidb-cloud/byoc/create-tidb-instance-byoc.md index b5088eed497f3..c51a635ff8af8 100644 --- a/tidb-cloud/byoc/create-tidb-instance-byoc.md +++ b/tidb-cloud/byoc/create-tidb-instance-byoc.md @@ -51,7 +51,7 @@ If you have the required permissions, you can create a {{{ .byoc }}} instance as 7. In the **Capacity** area, set the maximum number of Request Capacity Units (RCUs) for your instance. RCUs represent the compute resources provisioned for your workload. TiDB Cloud automatically scales your instance within this range based on demand. -8. For {{{ .byoc }}} instances, the high availability mode is inherited from the selected resource pool. If the resource pool uses regional high availability, the instance uses regional high availability. If the resource pool uses zonal high availability, the instance uses zonal high availability. You cannot configure the high availability mode when you create a BYOC instance. For more information, see [High Availability](/tidb-cloud/serverless-high-availability.md). +8. For {{{ .byoc }}} instances, the high availability mode is inherited from the selected resource pool. If the resource pool uses Regional high availability, the instance uses Regional high availability. If the resource pool uses Zonal high availability, the instance uses Zonal high availability. You cannot configure the high availability mode when you create a BYOC instance. For more information, see [TiDB Cloud BYOC architecture](/tidb-cloud/architecture-concepts.md#tidb-cloud-byoc). 9. Click **Create**. diff --git a/tidb-cloud/byoc/manage-resource-pools-byoc.md b/tidb-cloud/byoc/manage-resource-pools-byoc.md index 7dd242c5fe2dd..e246dd10682ca 100644 --- a/tidb-cloud/byoc/manage-resource-pools-byoc.md +++ b/tidb-cloud/byoc/manage-resource-pools-byoc.md @@ -43,6 +43,7 @@ To view resource pool details, click the name of a resource pool on the **Resour The resource pool details page includes the following information: +- **High Availability**: shows whether the resource pool uses Zonal or Regional high availability. This value is read-only. You cannot change the high availability mode or availability zone placement after the resource pool is created. - **Pool vCPU Usage**: shows the current provisioned TiDB vCPU and additional vCPU provision. - **Instances in This Pool**: lists the BYOC instances that run in this resource pool. - **Metrics**: shows vCPU usage and physical storage usage trends. diff --git a/tidb-cloud/byoc/multi-region-deployment.md b/tidb-cloud/byoc/multi-region-deployment.md index a6d1e2529a508..aa84c463abf93 100644 --- a/tidb-cloud/byoc/multi-region-deployment.md +++ b/tidb-cloud/byoc/multi-region-deployment.md @@ -121,7 +121,7 @@ Use `tidbcloud-byoc-update.sh` to update the existing CloudFormation stacks. The Before running the update script: 1. Confirm the AWS Regions to be added. -2. Select the Availability Zones for the new regions. +2. Select the Availability Zones for the new regions. A Regional resource pool requires at least three eligible availability zones. If you plan to create Regional resource pools in a new region, confirm that the region can provide at least three eligible availability zones. 3. Plan the O11Y CIDR for each new region and the resource pool CIDRs for the resource pools you plan to create. Different regions can use the same O11Y CIDR. However, if you use metric integration to connect Grafana to multiple regions, use non-overlapping O11Y CIDRs for those regions. 4. Confirm whether each new region will: * share the existing PCA and TiDB hosted zone, or diff --git a/tidb-cloud/premium/backup-and-restore-premium.md b/tidb-cloud/premium/backup-and-restore-premium.md index 726537382f731..e8d137bd25d86 100644 --- a/tidb-cloud/premium/backup-and-restore-premium.md +++ b/tidb-cloud/premium/backup-and-restore-premium.md @@ -242,7 +242,7 @@ To restore your data to a new {{{ .premium }}} or {{{ - For {{{ .byoc }}}, select an active resource pool in the same cloud provider and region as the backup. If no suitable resource pool is available, an `Organization Owner` can create one before restoring the instance. Other roles cannot create resource pools. For more information, see [Create a Resource Pool](/tidb-cloud/byoc/create-resource-pool-byoc.md). + For {{{ .byoc }}}, select an active resource pool in the same cloud provider and region as the backup. The restored instance inherits the high availability mode of the selected resource pool. You can restore the same backup to a Zonal or Regional resource pool if the resource pool meets the restore requirements. If no suitable resource pool is available, an `Organization Owner` can create one before restoring the instance. Other roles cannot create resource pools. For more information, see [Create a Resource Pool](/tidb-cloud/byoc/create-resource-pool-byoc.md). @@ -366,7 +366,7 @@ To restore backups from cloud storage, do the following: - For {{{ .byoc }}}, select an active resource pool that matches the target cloud provider and region. If no suitable resource pool is available, an `Organization Owner` can create one before restoring the instance. Other roles cannot create resource pools. For more information, see [Create a Resource Pool](/tidb-cloud/byoc/create-resource-pool-byoc.md). + For {{{ .byoc }}}, select an active resource pool that matches the target cloud provider and region. The restored instance inherits the high availability mode of the selected resource pool. You can restore the same backup to a Zonal or Regional resource pool if the resource pool meets the restore requirements. If no suitable resource pool is available, an `Organization Owner` can create one before restoring the instance. Other roles cannot create resource pools. For more information, see [Create a Resource Pool](/tidb-cloud/byoc/create-resource-pool-byoc.md). From 2c98237fd867e3db0aa13e86a4be8d5f826bcd6a Mon Sep 17 00:00:00 2001 From: Cheng Weiwei <65707268+wildpcww@users.noreply.github.com> Date: Mon, 24 Aug 2026 14:33:42 +0800 Subject: [PATCH 02/20] update create instance with limit content --- tidb-cloud/byoc/byoc-initialize-service.md | 2 +- tidb-cloud/byoc/create-tidb-instance-byoc.md | 6 ++++++ tidb-cloud/byoc/manage-resource-pools-byoc.md | 6 ++++++ tidb-cloud/premium/backup-and-restore-premium.md | 12 ++++++++++++ 4 files changed, 25 insertions(+), 1 deletion(-) diff --git a/tidb-cloud/byoc/byoc-initialize-service.md b/tidb-cloud/byoc/byoc-initialize-service.md index 7348810a9c3e6..bf71eb816de96 100644 --- a/tidb-cloud/byoc/byoc-initialize-service.md +++ b/tidb-cloud/byoc/byoc-initialize-service.md @@ -34,7 +34,7 @@ After preparing your backup file in Amazon S3, you can restore the data to a new Once the access keys are configured, you can initiate the restore job from the TiDB Cloud console. - During restore, select an active resource pool in the target cloud provider and region. The restored instance inherits the high availability mode of the selected resource pool. + During restore, select an active resource pool in the target cloud provider and region. The restored instance inherits the high availability mode of the selected resource pool. Make sure that the resource pool has sufficient vCPU capacity, because restoring an instance might cause the total provisioned vCPU to exceed the Pool vCPU Limit and degrade the performance of all instances in the resource pool. If the resource pool has reached its Pool vCPU Limit, increase or turn off the limit, or select another resource pool before continuing. For step-by-step restoration procedures, see [Restore backups from cloud storage](/tidb-cloud/premium/backup-and-restore-premium.md#restore-backups-from-cloud-storage). diff --git a/tidb-cloud/byoc/create-tidb-instance-byoc.md b/tidb-cloud/byoc/create-tidb-instance-byoc.md index c51a635ff8af8..c99772238623f 100644 --- a/tidb-cloud/byoc/create-tidb-instance-byoc.md +++ b/tidb-cloud/byoc/create-tidb-instance-byoc.md @@ -49,6 +49,12 @@ If you have the required permissions, you can create a {{{ .byoc }}} instance as Only resource pools that match the selected cloud provider and region and are in the **Active** status are displayed. If no suitable resource pool is available and you are an `Organization Owner`, click **Create Resource Pool** to create one. After the resource pool becomes active, it is automatically selected for the new instance. + If the selected resource pool has a Pool vCPU Limit and its current provisioned vCPU is greater than or equal to the limit, TiDB Cloud displays a warning and you cannot create the instance in that resource pool. To continue, go to the Resource Pool details page to increase or turn off the Pool vCPU Limit, or select another resource pool. + + > **Important:** + > + > Even if the current provisioned vCPU is below the Pool vCPU Limit, creating a new instance might cause the total provisioned vCPU to exceed the limit. This might constrain resource scaling and degrade the performance of all instances in the resource pool. Before creating the instance, make sure that the resource pool has sufficient vCPU capacity. If necessary, increase or turn off the Pool vCPU Limit, or select another resource pool. + 7. In the **Capacity** area, set the maximum number of Request Capacity Units (RCUs) for your instance. RCUs represent the compute resources provisioned for your workload. TiDB Cloud automatically scales your instance within this range based on demand. 8. For {{{ .byoc }}} instances, the high availability mode is inherited from the selected resource pool. If the resource pool uses Regional high availability, the instance uses Regional high availability. If the resource pool uses Zonal high availability, the instance uses Zonal high availability. You cannot configure the high availability mode when you create a BYOC instance. For more information, see [TiDB Cloud BYOC architecture](/tidb-cloud/architecture-concepts.md#tidb-cloud-byoc). diff --git a/tidb-cloud/byoc/manage-resource-pools-byoc.md b/tidb-cloud/byoc/manage-resource-pools-byoc.md index e246dd10682ca..96cb8b9e9d224 100644 --- a/tidb-cloud/byoc/manage-resource-pools-byoc.md +++ b/tidb-cloud/byoc/manage-resource-pools-byoc.md @@ -80,6 +80,12 @@ To update the Pool vCPU Limit, take the following steps: When you set a new Pool vCPU Limit, the value must be greater than or equal to `100` vCPU and the current provisioned TiDB vCPU. Otherwise, the update is rejected. +> **Important:** +> +> Even when the current provisioned vCPU is below the Pool vCPU Limit, creating or restoring an instance might cause the total provisioned vCPU to exceed the limit. This might constrain resource scaling and degrade the performance of all instances in the resource pool. Before creating or restoring an instance, make sure that the resource pool has sufficient vCPU capacity. + +If the current provisioned vCPU of a resource pool is greater than or equal to its Pool vCPU Limit, you cannot create or restore an instance in that resource pool. To create or restore an instance, increase or turn off the Pool vCPU Limit, or select another resource pool. + If the resource pool is in the **Modifying** status, **Update vCPU Limit** is disabled. ## Update capacity diff --git a/tidb-cloud/premium/backup-and-restore-premium.md b/tidb-cloud/premium/backup-and-restore-premium.md index e8d137bd25d86..dc3181d83056c 100644 --- a/tidb-cloud/premium/backup-and-restore-premium.md +++ b/tidb-cloud/premium/backup-and-restore-premium.md @@ -244,6 +244,12 @@ To restore your data to a new {{{ .premium }}} or {{{ For {{{ .byoc }}}, select an active resource pool in the same cloud provider and region as the backup. The restored instance inherits the high availability mode of the selected resource pool. You can restore the same backup to a Zonal or Regional resource pool if the resource pool meets the restore requirements. If no suitable resource pool is available, an `Organization Owner` can create one before restoring the instance. Other roles cannot create resource pools. For more information, see [Create a Resource Pool](/tidb-cloud/byoc/create-resource-pool-byoc.md). + If the selected resource pool has a Pool vCPU Limit and its current provisioned vCPU is greater than or equal to the limit, TiDB Cloud displays a warning and you cannot restore the instance to that resource pool. To continue, go to the Resource Pool details page to increase or turn off the Pool vCPU Limit, or select another resource pool. + + > **Important:** + > + > Even if the current provisioned vCPU is below the Pool vCPU Limit, restoring an instance might cause the total provisioned vCPU to exceed the limit. This might constrain resource scaling and degrade the performance of all instances in the resource pool. Before restoring the instance, make sure that the resource pool has sufficient vCPU capacity. If necessary, increase or turn off the Pool vCPU Limit, or select another resource pool. + > **Note:** @@ -368,6 +374,12 @@ To restore backups from cloud storage, do the following: For {{{ .byoc }}}, select an active resource pool that matches the target cloud provider and region. The restored instance inherits the high availability mode of the selected resource pool. You can restore the same backup to a Zonal or Regional resource pool if the resource pool meets the restore requirements. If no suitable resource pool is available, an `Organization Owner` can create one before restoring the instance. Other roles cannot create resource pools. For more information, see [Create a Resource Pool](/tidb-cloud/byoc/create-resource-pool-byoc.md). + If the selected resource pool has a Pool vCPU Limit and its current provisioned vCPU is greater than or equal to the limit, TiDB Cloud displays a warning and you cannot restore the instance to that resource pool. To continue, go to the Resource Pool details page to increase or turn off the Pool vCPU Limit, or select another resource pool. + + > **Important:** + > + > Even if the current provisioned vCPU is below the Pool vCPU Limit, restoring an instance might cause the total provisioned vCPU to exceed the limit. This might constrain resource scaling and degrade the performance of all instances in the resource pool. Before restoring the instance, make sure that the resource pool has sufficient vCPU capacity. If necessary, increase or turn off the Pool vCPU Limit, or select another resource pool. + If the backup information is incorrect, click **Previous** to return to the previous page, and then enter the correct information. From 471b3ad7773a805fee72f5b48f462ffe4f88eed5 Mon Sep 17 00:00:00 2001 From: Cheng Weiwei <65707268+wildpcww@users.noreply.github.com> Date: Tue, 25 Aug 2026 14:24:29 +0800 Subject: [PATCH 03/20] Apply suggestion from @qiancai Co-authored-by: Grace Cai --- tidb-cloud/byoc/byoc-initialize-service.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/tidb-cloud/byoc/byoc-initialize-service.md b/tidb-cloud/byoc/byoc-initialize-service.md index bf71eb816de96..5386bc1e46b09 100644 --- a/tidb-cloud/byoc/byoc-initialize-service.md +++ b/tidb-cloud/byoc/byoc-initialize-service.md @@ -11,7 +11,11 @@ After deploying your BYOC infrastructure, create a resource pool, create your fi You can now provision resource pools and TiDB instances directly via the TiDB Cloud console. -1. Create a resource pool. Log in to the [TiDB Cloud console](https://tidbcloud.com/) and follow the instructions in [Create a Resource Pool](/tidb-cloud/byoc/create-resource-pool-byoc.md) to create a resource pool in the target cloud provider and region. When creating the resource pool, select Zonal or Regional high availability based on your workload requirements. Instances created or restored in the resource pool inherit its high availability mode. +1. Log in to the [TiDB Cloud console](https://tidbcloud.com/), and then follow the instructions in [Create a Resource Pool](/tidb-cloud/byoc/create-resource-pool-byoc.md) to create a resource pool in the target cloud provider and region. + + >**Note:** + > + > When creating the resource pool, select **Zonal** or **Regional** high availability based on your workload requirements. {{{ .byoc }}} instances created or restored in the resource pool inherit the high availability mode of the pool. 2. After the resource pool becomes **Active**, follow the instructions in [Create a {{{ .byoc }}} Instance](/tidb-cloud/byoc/create-tidb-instance-byoc.md) to create a new instance in the resource pool. From f9575e247134cdd3e2ea16f36c35db96ac807cb8 Mon Sep 17 00:00:00 2001 From: Cheng Weiwei <65707268+wildpcww@users.noreply.github.com> Date: Tue, 25 Aug 2026 14:24:49 +0800 Subject: [PATCH 04/20] Apply suggestion from @qiancai Co-authored-by: Grace Cai --- tidb-cloud/byoc/byoc-initialize-service.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/tidb-cloud/byoc/byoc-initialize-service.md b/tidb-cloud/byoc/byoc-initialize-service.md index 5386bc1e46b09..f1cf20fdbe304 100644 --- a/tidb-cloud/byoc/byoc-initialize-service.md +++ b/tidb-cloud/byoc/byoc-initialize-service.md @@ -38,7 +38,9 @@ After preparing your backup file in Amazon S3, you can restore the data to a new Once the access keys are configured, you can initiate the restore job from the TiDB Cloud console. - During restore, select an active resource pool in the target cloud provider and region. The restored instance inherits the high availability mode of the selected resource pool. Make sure that the resource pool has sufficient vCPU capacity, because restoring an instance might cause the total provisioned vCPU to exceed the Pool vCPU Limit and degrade the performance of all instances in the resource pool. If the resource pool has reached its Pool vCPU Limit, increase or turn off the limit, or select another resource pool before continuing. + During restore, select an active resource pool with sufficient vCPU capacity in the target cloud provider and region. The restored instance inherits the high availability mode of the selected resource pool. + + If the selected resource pool has reached its Pool vCPU Limit, increase or turn off the limit, or select another resource pool before continuing. This is because restoring to a new {{{ .byoc }}} instance might cause the total provisioned vCPUs to exceed the Pool vCPU Limit and affect the performance of all {{{ .byoc }}} instances in the same pool. For step-by-step restoration procedures, see [Restore backups from cloud storage](/tidb-cloud/premium/backup-and-restore-premium.md#restore-backups-from-cloud-storage). From 3c3541f66b9a41675f29a100453a4ac72d75c3e3 Mon Sep 17 00:00:00 2001 From: Cheng Weiwei <65707268+wildpcww@users.noreply.github.com> Date: Tue, 25 Aug 2026 14:25:24 +0800 Subject: [PATCH 05/20] Apply suggestion from @qiancai Co-authored-by: Grace Cai --- tidb-cloud/byoc/byoc-prepare-environment-aws.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tidb-cloud/byoc/byoc-prepare-environment-aws.md b/tidb-cloud/byoc/byoc-prepare-environment-aws.md index 803813775df5b..34563518de7ef 100644 --- a/tidb-cloud/byoc/byoc-prepare-environment-aws.md +++ b/tidb-cloud/byoc/byoc-prepare-environment-aws.md @@ -37,7 +37,7 @@ TiDB is a distributed database that requires specific infrastructure for high av - **Option B: POC / Cost Optimization (Single-AZ).** Select exactly **1 AZ**. For example, `us-west-2a`. -The availability zones prepared for the BYOC region determine where TiDB Cloud can place resource pools. When creating a resource pool, you select either Zonal or Regional high availability. A Zonal resource pool is placed in one availability zone. A Regional resource pool requires at least three eligible availability zones in the region. +The availability zones prepared for the BYOC region determine where TiDB Cloud places resource pools. When creating a resource pool, you select either **Zonal** or **Regional** high availability. A zonal resource pool is placed in one availability zone. A regional resource pool requires at least three eligible availability zones in the region. If the BYOC region is initially prepared with a single availability zone, TiDB Cloud uses that availability zone for Zonal resource pools. You can create a Regional resource pool only when two additional eligible availability zones are available. If you plan to use Regional resource pools, confirm during environment preparation that the region can provide at least three eligible availability zones. From 64081501081ae8e140f1fee5ab7a78a959fce13d Mon Sep 17 00:00:00 2001 From: Cheng Weiwei <65707268+wildpcww@users.noreply.github.com> Date: Tue, 25 Aug 2026 14:26:21 +0800 Subject: [PATCH 06/20] Apply suggestion from @qiancai Co-authored-by: Grace Cai --- tidb-cloud/byoc/byoc-prepare-environment-aws.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tidb-cloud/byoc/byoc-prepare-environment-aws.md b/tidb-cloud/byoc/byoc-prepare-environment-aws.md index 34563518de7ef..178696da5d276 100644 --- a/tidb-cloud/byoc/byoc-prepare-environment-aws.md +++ b/tidb-cloud/byoc/byoc-prepare-environment-aws.md @@ -39,7 +39,7 @@ TiDB is a distributed database that requires specific infrastructure for high av The availability zones prepared for the BYOC region determine where TiDB Cloud places resource pools. When creating a resource pool, you select either **Zonal** or **Regional** high availability. A zonal resource pool is placed in one availability zone. A regional resource pool requires at least three eligible availability zones in the region. -If the BYOC region is initially prepared with a single availability zone, TiDB Cloud uses that availability zone for Zonal resource pools. You can create a Regional resource pool only when two additional eligible availability zones are available. If you plan to use Regional resource pools, confirm during environment preparation that the region can provide at least three eligible availability zones. +If a BYOC region is initially prepared with a single availability zone, TiDB Cloud uses that availability zone for zonal resource pools. You can create a regional resource pool only when two additional eligible availability zones are available. If you plan to use regional resource pools, confirm during environment preparation that the region provides at least three eligible availability zones. ## Step 4. Create a hosted zone for TiDB From cfbe26c536344e4fff7c52508ab5ee657f5f3a07 Mon Sep 17 00:00:00 2001 From: Cheng Weiwei <65707268+wildpcww@users.noreply.github.com> Date: Tue, 25 Aug 2026 14:27:32 +0800 Subject: [PATCH 07/20] Apply suggestion from @qiancai Co-authored-by: Grace Cai --- tidb-cloud/byoc/create-resource-pool-byoc.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tidb-cloud/byoc/create-resource-pool-byoc.md b/tidb-cloud/byoc/create-resource-pool-byoc.md index e38ed78a754d1..4c0f1bf85d76d 100644 --- a/tidb-cloud/byoc/create-resource-pool-byoc.md +++ b/tidb-cloud/byoc/create-resource-pool-byoc.md @@ -51,7 +51,7 @@ To create a resource pool, take the following steps: 6. In the **High Availability** area, select a high availability mode for the resource pool. - **Zonal**: deploys the resource pool in a single availability zone for lower network latency. - - **Regional**: deploys the resource pool across multiple availability zones for higher availability and resilience against an availability-zone-level outage. + - **Regional**: deploys the resource pool across multiple availability zones for higher availability and resilience to outages at the availability zone level. You must select a high availability mode before creating the resource pool. You cannot select the specific availability zones. TiDB Cloud determines the availability zones based on the BYOC region configuration and available cloud resources. From 169b43a43ff06c26a2fd593f974ab34d6cbd8ea6 Mon Sep 17 00:00:00 2001 From: Cheng Weiwei <65707268+wildpcww@users.noreply.github.com> Date: Tue, 25 Aug 2026 14:27:58 +0800 Subject: [PATCH 08/20] Apply suggestion from @qiancai Co-authored-by: Grace Cai --- tidb-cloud/byoc/create-tidb-instance-byoc.md | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/tidb-cloud/byoc/create-tidb-instance-byoc.md b/tidb-cloud/byoc/create-tidb-instance-byoc.md index c99772238623f..67e7e6b332e14 100644 --- a/tidb-cloud/byoc/create-tidb-instance-byoc.md +++ b/tidb-cloud/byoc/create-tidb-instance-byoc.md @@ -49,11 +49,10 @@ If you have the required permissions, you can create a {{{ .byoc }}} instance as Only resource pools that match the selected cloud provider and region and are in the **Active** status are displayed. If no suitable resource pool is available and you are an `Organization Owner`, click **Create Resource Pool** to create one. After the resource pool becomes active, it is automatically selected for the new instance. - If the selected resource pool has a Pool vCPU Limit and its current provisioned vCPU is greater than or equal to the limit, TiDB Cloud displays a warning and you cannot create the instance in that resource pool. To continue, go to the Resource Pool details page to increase or turn off the Pool vCPU Limit, or select another resource pool. + Make sure to select a resource pool with sufficient vCPU capacity. Otherwise, the following issues can occur. - > **Important:** - > - > Even if the current provisioned vCPU is below the Pool vCPU Limit, creating a new instance might cause the total provisioned vCPU to exceed the limit. This might constrain resource scaling and degrade the performance of all instances in the resource pool. Before creating the instance, make sure that the resource pool has sufficient vCPU capacity. If necessary, increase or turn off the Pool vCPU Limit, or select another resource pool. + - If the selected resource pool has a Pool vCPU Limit and its current provisioned vCPU is greater than or equal to the limit, TiDB Cloud displays a warning, and you cannot create the {{{ .byoc }}} instance in that resource pool. To continue, go to the **Resource Pool** details page of the pool to increase or turn off the Pool vCPU Limit, or select another resource pool. + - Even if the current provisioned vCPUs are below the Pool vCPU Limit, creating a new instance might cause the total provisioned vCPUs to exceed the limit. This might restrict resource scaling and affect the performance of all instances in the resource pool. If necessary, increase or turn off the Pool vCPU Limit, or select another resource pool. 7. In the **Capacity** area, set the maximum number of Request Capacity Units (RCUs) for your instance. RCUs represent the compute resources provisioned for your workload. TiDB Cloud automatically scales your instance within this range based on demand. From 1d3c9e79eac1a0e1e1124b638142129ff86f8032 Mon Sep 17 00:00:00 2001 From: Cheng Weiwei <65707268+wildpcww@users.noreply.github.com> Date: Tue, 25 Aug 2026 14:28:08 +0800 Subject: [PATCH 09/20] Apply suggestion from @qiancai Co-authored-by: Grace Cai --- tidb-cloud/byoc/create-tidb-instance-byoc.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tidb-cloud/byoc/create-tidb-instance-byoc.md b/tidb-cloud/byoc/create-tidb-instance-byoc.md index 67e7e6b332e14..3a9ab3ece2c73 100644 --- a/tidb-cloud/byoc/create-tidb-instance-byoc.md +++ b/tidb-cloud/byoc/create-tidb-instance-byoc.md @@ -56,7 +56,7 @@ If you have the required permissions, you can create a {{{ .byoc }}} instance as 7. In the **Capacity** area, set the maximum number of Request Capacity Units (RCUs) for your instance. RCUs represent the compute resources provisioned for your workload. TiDB Cloud automatically scales your instance within this range based on demand. -8. For {{{ .byoc }}} instances, the high availability mode is inherited from the selected resource pool. If the resource pool uses Regional high availability, the instance uses Regional high availability. If the resource pool uses Zonal high availability, the instance uses Zonal high availability. You cannot configure the high availability mode when you create a BYOC instance. For more information, see [TiDB Cloud BYOC architecture](/tidb-cloud/architecture-concepts.md#tidb-cloud-byoc). +8. For {{{ .byoc }}} instances, the high availability mode is inherited from the selected resource pool. If the resource pool uses regional high availability, the instance uses regional high availability. If the resource pool uses zonal high availability, the instance uses zonal high availability. You cannot configure the high availability mode when you create a BYOC instance. For more information, see [TiDB Cloud BYOC architecture](/tidb-cloud/architecture-concepts.md#tidb-cloud-byoc). 9. Click **Create**. From acec4ac1eef2b1dc7a03325b47fd44ee92fd1f10 Mon Sep 17 00:00:00 2001 From: Cheng Weiwei <65707268+wildpcww@users.noreply.github.com> Date: Tue, 25 Aug 2026 14:28:26 +0800 Subject: [PATCH 10/20] Apply suggestion from @qiancai Co-authored-by: Grace Cai --- tidb-cloud/byoc/manage-resource-pools-byoc.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tidb-cloud/byoc/manage-resource-pools-byoc.md b/tidb-cloud/byoc/manage-resource-pools-byoc.md index 96cb8b9e9d224..b901772b18cf9 100644 --- a/tidb-cloud/byoc/manage-resource-pools-byoc.md +++ b/tidb-cloud/byoc/manage-resource-pools-byoc.md @@ -43,7 +43,7 @@ To view resource pool details, click the name of a resource pool on the **Resour The resource pool details page includes the following information: -- **High Availability**: shows whether the resource pool uses Zonal or Regional high availability. This value is read-only. You cannot change the high availability mode or availability zone placement after the resource pool is created. +- **High Availability**: shows whether the resource pool uses zonal or regional high availability. This value is read-only. You cannot change the high availability mode or availability zone placement after the resource pool is created. - **Pool vCPU Usage**: shows the current provisioned TiDB vCPU and additional vCPU provision. - **Instances in This Pool**: lists the BYOC instances that run in this resource pool. - **Metrics**: shows vCPU usage and physical storage usage trends. From 0812533acf63de3f2d35ec86a5118672fefb87b8 Mon Sep 17 00:00:00 2001 From: Cheng Weiwei <65707268+wildpcww@users.noreply.github.com> Date: Tue, 25 Aug 2026 14:29:08 +0800 Subject: [PATCH 11/20] Apply suggestion from @qiancai Co-authored-by: Grace Cai --- tidb-cloud/byoc/manage-resource-pools-byoc.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tidb-cloud/byoc/manage-resource-pools-byoc.md b/tidb-cloud/byoc/manage-resource-pools-byoc.md index b901772b18cf9..3f439a2727e3a 100644 --- a/tidb-cloud/byoc/manage-resource-pools-byoc.md +++ b/tidb-cloud/byoc/manage-resource-pools-byoc.md @@ -80,7 +80,7 @@ To update the Pool vCPU Limit, take the following steps: When you set a new Pool vCPU Limit, the value must be greater than or equal to `100` vCPU and the current provisioned TiDB vCPU. Otherwise, the update is rejected. -> **Important:** +> **Note:** > > Even when the current provisioned vCPU is below the Pool vCPU Limit, creating or restoring an instance might cause the total provisioned vCPU to exceed the limit. This might constrain resource scaling and degrade the performance of all instances in the resource pool. Before creating or restoring an instance, make sure that the resource pool has sufficient vCPU capacity. From 275fef3744125a504e1ea55b53411040a34069e1 Mon Sep 17 00:00:00 2001 From: Cheng Weiwei <65707268+wildpcww@users.noreply.github.com> Date: Tue, 25 Aug 2026 14:29:46 +0800 Subject: [PATCH 12/20] Apply suggestions from code review Co-authored-by: Grace Cai --- tidb-cloud/architecture-concepts.md | 2 +- tidb-cloud/byoc/manage-resource-pools-byoc.md | 2 +- tidb-cloud/premium/backup-and-restore-premium.md | 6 +++--- 3 files changed, 5 insertions(+), 5 deletions(-) diff --git a/tidb-cloud/architecture-concepts.md b/tidb-cloud/architecture-concepts.md index 81fefae04d5ce..d91d83d7799bd 100644 --- a/tidb-cloud/architecture-concepts.md +++ b/tidb-cloud/architecture-concepts.md @@ -104,7 +104,7 @@ BYOC provides the following features: To meet different workload requirements, TiDB Cloud BYOC supports both Single-AZ and Multi-AZ deployments, enabling you to choose between lower-latency zonal deployment and higher-resilience deployment across multiple availability zones. -High availability is configured for each resource pool. A Zonal resource pool is deployed in a single availability zone, while a Regional resource pool is deployed across multiple availability zones. TiDB Cloud determines the availability zone placement based on the BYOC region configuration and available cloud resources. Instances created or restored in a resource pool inherit its high availability mode. After a resource pool is created, you cannot change its high availability mode or availability zone placement. +You can configure high availability mode for each resource pool as **Zonal** or **Regional** when you [create the pool](/tidb-cloud/byoc/create-resource-pool-byoc.md). A zonal resource pool is deployed in a single availability zone, while a regional resource pool is deployed across multiple availability zones. TiDB Cloud determines the availability zone placement based on the BYOC region configuration and available cloud resources. TiDB Cloud BYOC instances created or restored in a resource pool inherit the high availability mode of the pool. After a resource pool is created, you cannot change its high availability mode or availability zone placement. ![TiDB Cloud BYOC Architecture](/media/tidb-cloud/byoc-architecture.png) diff --git a/tidb-cloud/byoc/manage-resource-pools-byoc.md b/tidb-cloud/byoc/manage-resource-pools-byoc.md index 3f439a2727e3a..4e4ebae3a3419 100644 --- a/tidb-cloud/byoc/manage-resource-pools-byoc.md +++ b/tidb-cloud/byoc/manage-resource-pools-byoc.md @@ -82,7 +82,7 @@ When you set a new Pool vCPU Limit, the value must be greater than or equal to ` > **Note:** > -> Even when the current provisioned vCPU is below the Pool vCPU Limit, creating or restoring an instance might cause the total provisioned vCPU to exceed the limit. This might constrain resource scaling and degrade the performance of all instances in the resource pool. Before creating or restoring an instance, make sure that the resource pool has sufficient vCPU capacity. +> Even when the current provisioned vCPU is below the Pool vCPU Limit, creating or restoring an instance might cause the total provisioned vCPU to exceed the limit. This might restrict resource scaling and degrade the performance of all instances in the resource pool. Before creating or restoring an instance, make sure that the resource pool has sufficient vCPU capacity. If the current provisioned vCPU of a resource pool is greater than or equal to its Pool vCPU Limit, you cannot create or restore an instance in that resource pool. To create or restore an instance, increase or turn off the Pool vCPU Limit, or select another resource pool. diff --git a/tidb-cloud/premium/backup-and-restore-premium.md b/tidb-cloud/premium/backup-and-restore-premium.md index dc3181d83056c..99f6e97883f10 100644 --- a/tidb-cloud/premium/backup-and-restore-premium.md +++ b/tidb-cloud/premium/backup-and-restore-premium.md @@ -246,7 +246,7 @@ To restore your data to a new {{{ .premium }}} or {{{ If the selected resource pool has a Pool vCPU Limit and its current provisioned vCPU is greater than or equal to the limit, TiDB Cloud displays a warning and you cannot restore the instance to that resource pool. To continue, go to the Resource Pool details page to increase or turn off the Pool vCPU Limit, or select another resource pool. - > **Important:** + > **Note:** > > Even if the current provisioned vCPU is below the Pool vCPU Limit, restoring an instance might cause the total provisioned vCPU to exceed the limit. This might constrain resource scaling and degrade the performance of all instances in the resource pool. Before restoring the instance, make sure that the resource pool has sufficient vCPU capacity. If necessary, increase or turn off the Pool vCPU Limit, or select another resource pool. @@ -376,9 +376,9 @@ To restore backups from cloud storage, do the following: If the selected resource pool has a Pool vCPU Limit and its current provisioned vCPU is greater than or equal to the limit, TiDB Cloud displays a warning and you cannot restore the instance to that resource pool. To continue, go to the Resource Pool details page to increase or turn off the Pool vCPU Limit, or select another resource pool. - > **Important:** + > **Note:** > - > Even if the current provisioned vCPU is below the Pool vCPU Limit, restoring an instance might cause the total provisioned vCPU to exceed the limit. This might constrain resource scaling and degrade the performance of all instances in the resource pool. Before restoring the instance, make sure that the resource pool has sufficient vCPU capacity. If necessary, increase or turn off the Pool vCPU Limit, or select another resource pool. + > Even if the current provisioned vCPU is below the Pool vCPU Limit, restoring an instance might cause the total provisioned vCPU to exceed the limit. This might restrict resource scaling and affect the performance of all instances in the resource pool. Before restoring the instance, make sure that the resource pool has sufficient vCPU capacity. If necessary, increase or turn off the Pool vCPU Limit, or select another resource pool. From 1ba4376260c5437bea76301238fa39bd03529cc6 Mon Sep 17 00:00:00 2001 From: Cheng Weiwei <65707268+wildpcww@users.noreply.github.com> Date: Tue, 25 Aug 2026 14:44:17 +0800 Subject: [PATCH 13/20] Apply suggestion from @qiancai Co-authored-by: Grace Cai --- tidb-cloud/byoc/create-resource-pool-byoc.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/tidb-cloud/byoc/create-resource-pool-byoc.md b/tidb-cloud/byoc/create-resource-pool-byoc.md index 4c0f1bf85d76d..6e797006b36b1 100644 --- a/tidb-cloud/byoc/create-resource-pool-byoc.md +++ b/tidb-cloud/byoc/create-resource-pool-byoc.md @@ -53,7 +53,11 @@ To create a resource pool, take the following steps: - **Zonal**: deploys the resource pool in a single availability zone for lower network latency. - **Regional**: deploys the resource pool across multiple availability zones for higher availability and resilience to outages at the availability zone level. - You must select a high availability mode before creating the resource pool. You cannot select the specific availability zones. TiDB Cloud determines the availability zones based on the BYOC region configuration and available cloud resources. +>**Note:** +> +> - You must select a high availability mode before creating the resource pool. +> - If you select the **Regional** mode, make sure that the region for this pool contains at least three eligible availability zones. If this requirement is not met, the process of creating the regional resource pool might get stuck. +> - TiDB Cloud determines the availability zones based on the [BYOC region configuration](/tidb-cloud/byoc/byoc-prepare-environment-aws.md#step-3-select-region-and-availability-zones-azs) and available cloud resources. To create a Regional resource pool, at least three eligible availability zones must be available in the region. If this requirement is not met, you cannot create the Regional resource pool. From 58ca6ad17fbea2a196a48711a83ed2147f4663f8 Mon Sep 17 00:00:00 2001 From: Cheng Weiwei <65707268+wildpcww@users.noreply.github.com> Date: Tue, 25 Aug 2026 14:44:34 +0800 Subject: [PATCH 14/20] Apply suggestion from @qiancai Co-authored-by: Grace Cai --- tidb-cloud/byoc/create-resource-pool-byoc.md | 2 -- 1 file changed, 2 deletions(-) diff --git a/tidb-cloud/byoc/create-resource-pool-byoc.md b/tidb-cloud/byoc/create-resource-pool-byoc.md index 6e797006b36b1..edcf08542135b 100644 --- a/tidb-cloud/byoc/create-resource-pool-byoc.md +++ b/tidb-cloud/byoc/create-resource-pool-byoc.md @@ -59,8 +59,6 @@ To create a resource pool, take the following steps: > - If you select the **Regional** mode, make sure that the region for this pool contains at least three eligible availability zones. If this requirement is not met, the process of creating the regional resource pool might get stuck. > - TiDB Cloud determines the availability zones based on the [BYOC region configuration](/tidb-cloud/byoc/byoc-prepare-environment-aws.md#step-3-select-region-and-availability-zones-azs) and available cloud resources. - To create a Regional resource pool, at least three eligible availability zones must be available in the region. If this requirement is not met, you cannot create the Regional resource pool. - After the resource pool is created, you cannot change its high availability mode or availability zone placement. 7. In the **Pool CIDR** area, review or enter the CIDR range for the resource pool. From e6f201be7691ead5ada881d917ef0266202974b4 Mon Sep 17 00:00:00 2001 From: Cheng Weiwei <65707268+wildpcww@users.noreply.github.com> Date: Tue, 25 Aug 2026 14:59:49 +0800 Subject: [PATCH 15/20] Apply suggestion from @qiancai Co-authored-by: Grace Cai --- tidb-cloud/byoc/multi-region-deployment.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tidb-cloud/byoc/multi-region-deployment.md b/tidb-cloud/byoc/multi-region-deployment.md index aa84c463abf93..1d9b88d72f8bb 100644 --- a/tidb-cloud/byoc/multi-region-deployment.md +++ b/tidb-cloud/byoc/multi-region-deployment.md @@ -121,7 +121,7 @@ Use `tidbcloud-byoc-update.sh` to update the existing CloudFormation stacks. The Before running the update script: 1. Confirm the AWS Regions to be added. -2. Select the Availability Zones for the new regions. A Regional resource pool requires at least three eligible availability zones. If you plan to create Regional resource pools in a new region, confirm that the region can provide at least three eligible availability zones. +2. Select the Availability Zones for the new regions. A regional resource pool requires at least three eligible availability zones. If you plan to create regional resource pools in a new region, select at least three eligible availability zones for that region. 3. Plan the O11Y CIDR for each new region and the resource pool CIDRs for the resource pools you plan to create. Different regions can use the same O11Y CIDR. However, if you use metric integration to connect Grafana to multiple regions, use non-overlapping O11Y CIDRs for those regions. 4. Confirm whether each new region will: * share the existing PCA and TiDB hosted zone, or From 2442354c9097baf8d095b2dc213daee3dfb42aed Mon Sep 17 00:00:00 2001 From: Cheng Weiwei <65707268+wildpcww@users.noreply.github.com> Date: Tue, 25 Aug 2026 16:51:32 +0800 Subject: [PATCH 16/20] Apply suggestions from code review Co-authored-by: Cheng Weiwei <65707268+wildpcww@users.noreply.github.com> --- .../premium/backup-and-restore-premium.md | 996 +++++++++--------- 1 file changed, 498 insertions(+), 498 deletions(-) diff --git a/tidb-cloud/premium/backup-and-restore-premium.md b/tidb-cloud/premium/backup-and-restore-premium.md index 99f6e97883f10..614a51cf5a1f4 100644 --- a/tidb-cloud/premium/backup-and-restore-premium.md +++ b/tidb-cloud/premium/backup-and-restore-premium.md @@ -1,501 +1,501 @@ ---- -title: Back Up and Restore {{{ .premium }}} Data -summary: Learn how to back up and restore your {{{ .premium }}} instances. -aliases: ['/tidbcloud/restore-deleted-tidb-cluster'] ---- - -# Back Up and Restore {{{ .premium }}} Data - - - -This document describes how to back up and restore your data on {{{ .premium }}} instances. {{{ .premium }}} supports both automatic backups and manual backups, and lets you restore backup data to a new instance as needed. - - - - - -This document describes how to back up and restore your data on {{{ .premium }}} or {{{ .byoc }}} instances. {{{ .premium }}} and {{{ .byoc }}} support both automatic backups and manual backups, and let you restore backup data to a new instance as needed. - - - -Backup files can originate from the following sources: - -- Active {{{ .premium }}} or {{{ .byoc }}} instances -- The Recycle Bin for backups from deleted {{{ .premium }}} or {{{ .byoc }}} instances - -> **Tip:** -> -> - To learn how to back up and restore data on {{{ .dedicated }}} clusters, see [Back Up and Restore {{{ .dedicated }}} Data](/tidb-cloud/backup-and-restore.md). -> - To learn how to back up and restore data on {{{ .starter }}} or {{{ .essential }}} instances, see [Back Up and Restore {{{ .starter }}} or Essential Data](/tidb-cloud/backup-and-restore-serverless.md). - -## View the Backup page - -1. On the [**My TiDB**](https://tidbcloud.com/tidbs) page, click the name of your target {{{ .premium }}} or {{{ .byoc }}} instance to go to its overview page. - - > **Tip:** - > - > If you are in multiple organizations, use the combo box in the upper-left corner to switch to your target organization first. - -2. In the left navigation pane, click **Data** > **Backup**. - -## Automatic backups - - - -{{{ .premium }}} provides enhanced automatic backup capabilities for production environments. It combines high-frequency snapshots with log backups to ensure data reliability. - - - - - -{{{ .premium }}} and {{{ .byoc }}} provide enhanced automatic backup capabilities for production environments. They combine high-frequency snapshots with log backups to ensure data reliability. - - - -### Automatic backup modes - -You can choose an automatic backup mode in **Backup Settings**. The available backup types, retention periods, and pricing model depend on the selected mode. - - - -| Backup mode | Supported backup types | Retention and restore options | Pricing model | -| --- | --- | --- | --- | -| **Standard Bundle Mode** |
  • PITR
  • Hourly backup snapshots
  • Daily backup snapshots
|
  • PITR: 7 days
  • Hourly snapshots: 7 days
  • Daily snapshots: 33 days
  • Daily snapshots are created at 00:00 UTC.
| Based on incremental data volume. | -| **Custom Retention Mode** |
  • PITR
  • Daily backup snapshots
| You can set the retention period from 3 to 33 days. PITR and daily snapshots use the configured retention period. | Based on snapshot size multiplied by retention duration. Each backup is billed as a separate object. | - - - - - -| Backup mode | Supported backup types | Retention and restore options | -| --- | --- | --- | -| **Standard Bundle Mode** |
  • PITR
  • Hourly backup snapshots
  • Daily backup snapshots
|
  • PITR: 7 days
  • Hourly snapshots: 7 days
  • Daily snapshots: 33 days
  • Daily snapshots are created at 00:00 UTC.
| -| **Custom Retention Mode** |
  • PITR
  • Daily backup snapshots
| You can set the retention period from 3 to 33 days. PITR and daily snapshots use the configured retention period. | - - - -PITR lets you restore data to any point in time within the retention period. A snapshot lets you restore data from a specific hourly or daily snapshot that is still within the retention period. - -### Configure automatic backups - -1. On the [**My TiDB**](https://tidbcloud.com/tidbs) page, click the name of your target {{{ .premium }}} or {{{ .byoc }}} instance. - -2. In the left navigation pane, click **Data** > **Backup**. - -3. In the upper-right corner, click **...**, and then click **Backup Settings**. - -4. Select an automatic backup mode: - - - **Standard Bundle Mode** uses predefined settings for PITR, hourly snapshots, and daily snapshots. - - **Custom Retention Mode** lets you specify the automatic backup retention period and daily backup time. - -5. If you select **Custom Retention Mode**, configure the following settings. Otherwise, skip this step. - - - **Backup Retention**: select a retention period from 3 to 33 days. The default value is 7 days. - - **Daily Backup Time**: select the time of day for the daily snapshot. The time zone is displayed next to the setting. - -6. Review the **Overview** section, and then click **Save**. - - The overview shows the backup types enabled by the selected backup mode, the corresponding retention periods, and the available restore options. - - - -> **Note:** -> -> If you [switch between backup modes](#switch-between-automatic-backup-modes) or reduce the retention period, TiDB Cloud might permanently delete existing automatic backups that are older than the new retention period. This action cannot be undone. - - - - - -> **Note:** -> -> - Custom Retention Mode pricing is based on snapshot size and retention duration. PITR is temporarily free during the public preview period. See [TiDB Cloud pricing](https://www.pingcap.com/tidb-cloud-premium-pricing-details) for more information. -> - If you [switch between backup modes](#switch-between-automatic-backup-modes) or reduce the retention period, TiDB Cloud might permanently delete existing automatic backups that are older than the new retention period. This action cannot be undone. - - - -### Switch between automatic backup modes - -To switch between **Standard Bundle Mode** and **Custom Retention Mode**, take the following steps: - -1. Navigate to the [**Backup**](#view-the-backup-page) page of your instance. -2. In the upper-right corner, click **...**, and then click **Backup Settings**. -3. In the displayed dialog, select a new mode. - - - If you switch to **Custom Retention Mode**, you need to configure the backup retention period and daily backup time. - - If you switch to **Standard Bundle Mode**, the retention periods and daily backup time are reset to the standard bundle defaults. - -4. Review the retention settings in the **Overview** section, and then click **Save**. - - - -After you save the changes, future automatic backups are billed according to the pricing model of the selected mode. - - - -If the new retention period is shorter than the current retention period, the confirmation dialog lists the automatic backups that are older than the new retention period and will be permanently deleted. Confirm the operation only after verifying that you no longer need those backups. - -### Backup protection - -To help prevent data loss and preserve a recovery point, TiDB Cloud protects **the latest successful automatic backup** of an instance until its retention period expires. Therefore, you cannot manually delete this protected latest backup, even after the instance is deleted. If you attempt to delete it, the console displays a message explaining that the backup is protected and cannot be deleted before it expires. - -### Delete backup files - -To delete an existing backup file for your {{{ .premium }}} or {{{ .byoc }}} instance, perform the following steps: - -1. Navigate to the [**Backup**](#view-the-backup-page) page of your instance. - -2. Locate the corresponding backup file you want to delete, and click **...** > **Delete** in the **Action** column. - - > **Note:** - > - > TiDB Cloud protects the **latest successful automatic backup** of your instance to help prevent data loss. If you attempt to delete it, the console displays a message explaining that the backup is protected and cannot be deleted before it expires. - > If you have the `Organization Owner` or `Project Owner` role in TiDB Cloud, you can delete an automatic backup other than the latest successful one, or delete a manual backup. - -## Manual backups - - - -In addition to automatic backups, {{{ .premium }}} supports manual backups. A manual backup provides a controlled, guaranteed restore point. It is highly recommended that you create a manual backup before you perform high-risk operations such as system upgrades, critical data deletion, or irreversible schema or configuration changes. - - - - - -In addition to automatic backups, {{{ .premium }}} and {{{ .byoc }}} support manual backups. A manual backup provides a controlled, guaranteed restore point. It is highly recommended that you create a manual backup before you perform high-risk operations such as system upgrades, critical data deletion, or irreversible schema or configuration changes. - - - -### Key characteristics - -- **Retention and deletion**: unlike automatic backups, manual backups are not automatically deleted based on retention policies. They are retained until you explicitly delete them. If you delete the instance, its manual backups move to the recycle bin and remain there until you manually delete them. - -- **Storage location**: manual backups are stored in cloud storage managed by TiDB. - -- **Cost**: manual backups incur additional charges because they are retained until you delete them. - -- **Limitations**: manual backups do not support point-in-time recovery (PITR) or partial backups (for example, table-level or database-level backups). You cannot restore a manual backup to an existing instance. Each restore operation creates a new instance. - -- **Permissions**: both `Organization Owner` and `Instance Manager` can create manual backups. Only `Organization Owner` can restore system-managed manual backups. - -### Create a manual backup - -1. Navigate to the [**Backup**](#view-the-backup-page) page of your instance. - -2. In the upper-right corner, click **...**, and then click **Manual Backup**. - -3. Confirm the operation. The backup is stored in TiDB Cloud and will appear in the **Backup List**. - -You can restore a manual backup directly in the TiDB Cloud console without providing external storage credentials. - -## Restore - -TiDB Cloud provides restore functionality to help recover data in case of accidental loss or corruption. You can restore from backups of active instances or from deleted instances in the Recycle Bin. - -### Restore mode - -TiDB Cloud supports snapshot restore and point-in-time restore for your instance. - -- **Snapshot Restore**: restores your instance from a specific backup snapshot. You can use this method to restore both automatic and manual backups. In the **Backup List**, manual backups are labeled with the **Manual** type and a **Permanent** expiration status. - -- **Point-in-Time Restore**: restores your instance to a specific point in time. - - - Premium or BYOC instances: can be restored to any time within the last 7 days, but not earlier than the instance creation time or later than one minute before the current time. Note that PITR is not supported for manual backups. - -### Restore destination - -TiDB Cloud supports restoring data to a new instance. - -### Restore to a new {{{ .premium }}} instance {#restore-to-a-new-instance} - -To restore your data to a new {{{ .premium }}} or {{{ .byoc }}} instance, take the following steps: - -1. Navigate to the [**Backup**](#view-the-backup-page) page of your instance. - -2. Click **Restore**. - -3. On the **Select Backup** page, choose the **Restore Mode** you want to use. You can restore from a specific backup snapshot or restore to a specific point in time. - - -
- - To restore from a selected backup snapshot, take the following steps: - - 1. Click **Snapshot Restore**. - 2. Select the backup snapshot you want to restore from. - -
-
- - To restore to a specific point in time for a Premium or BYOC instance, take the following steps: - - 1. Click **Point-in-Time Restore**. - 2. Select the date and time you want to restore to. - -
- - -4. Click **Next** to proceed to the **Restore to a New Instance** page. - -5. Configure your new {{{ .premium }}} or {{{ .byoc }}} instance for restoration. Follow the steps in [Create a {{{ .premium }}} Instance](/tidb-cloud/premium/create-tidb-instance-premium.md)[Create a {{{ .byoc }}} Instance](/tidb-cloud/byoc/create-tidb-instance-byoc.md). - - - - For {{{ .byoc }}}, select an active resource pool in the same cloud provider and region as the backup. The restored instance inherits the high availability mode of the selected resource pool. You can restore the same backup to a Zonal or Regional resource pool if the resource pool meets the restore requirements. If no suitable resource pool is available, an `Organization Owner` can create one before restoring the instance. Other roles cannot create resource pools. For more information, see [Create a Resource Pool](/tidb-cloud/byoc/create-resource-pool-byoc.md). - - If the selected resource pool has a Pool vCPU Limit and its current provisioned vCPU is greater than or equal to the limit, TiDB Cloud displays a warning and you cannot restore the instance to that resource pool. To continue, go to the Resource Pool details page to increase or turn off the Pool vCPU Limit, or select another resource pool. - +--- +title: Back Up and Restore {{{ .premium }}} Data +summary: Learn how to back up and restore your {{{ .premium }}} instances. +aliases: ['/tidbcloud/restore-deleted-tidb-cluster'] +--- + +# Back Up and Restore {{{ .premium }}} Data + + + +This document describes how to back up and restore your data on {{{ .premium }}} instances. {{{ .premium }}} supports both automatic backups and manual backups, and lets you restore backup data to a new instance as needed. + + + + + +This document describes how to back up and restore your data on {{{ .premium }}} or {{{ .byoc }}} instances. {{{ .premium }}} and {{{ .byoc }}} support both automatic backups and manual backups, and let you restore backup data to a new instance as needed. + + + +Backup files can originate from the following sources: + +- Active {{{ .premium }}} or {{{ .byoc }}} instances +- The Recycle Bin for backups from deleted {{{ .premium }}} or {{{ .byoc }}} instances + +> **Tip:** +> +> - To learn how to back up and restore data on {{{ .dedicated }}} clusters, see [Back Up and Restore {{{ .dedicated }}} Data](/tidb-cloud/backup-and-restore.md). +> - To learn how to back up and restore data on {{{ .starter }}} or {{{ .essential }}} instances, see [Back Up and Restore {{{ .starter }}} or Essential Data](/tidb-cloud/backup-and-restore-serverless.md). + +## View the Backup page + +1. On the [**My TiDB**](https://tidbcloud.com/tidbs) page, click the name of your target {{{ .premium }}} or {{{ .byoc }}} instance to go to its overview page. + + > **Tip:** + > + > If you are in multiple organizations, use the combo box in the upper-left corner to switch to your target organization first. + +2. In the left navigation pane, click **Data** > **Backup**. + +## Automatic backups + + + +{{{ .premium }}} provides enhanced automatic backup capabilities for production environments. It combines high-frequency snapshots with log backups to ensure data reliability. + + + + + +{{{ .premium }}} and {{{ .byoc }}} provide enhanced automatic backup capabilities for production environments. They combine high-frequency snapshots with log backups to ensure data reliability. + + + +### Automatic backup modes + +You can choose an automatic backup mode in **Backup Settings**. The available backup types, retention periods, and pricing model depend on the selected mode. + + + +| Backup mode | Supported backup types | Retention and restore options | Pricing model | +| --- | --- | --- | --- | +| **Standard Bundle Mode** |
  • PITR
  • Hourly backup snapshots
  • Daily backup snapshots
|
  • PITR: 7 days
  • Hourly snapshots: 7 days
  • Daily snapshots: 33 days
  • Daily snapshots are created at 00:00 UTC.
| Based on incremental data volume. | +| **Custom Retention Mode** |
  • PITR
  • Daily backup snapshots
| You can set the retention period from 3 to 33 days. PITR and daily snapshots use the configured retention period. | Based on snapshot size multiplied by retention duration. Each backup is billed as a separate object. | + + + + + +| Backup mode | Supported backup types | Retention and restore options | +| --- | --- | --- | +| **Standard Bundle Mode** |
  • PITR
  • Hourly backup snapshots
  • Daily backup snapshots
|
  • PITR: 7 days
  • Hourly snapshots: 7 days
  • Daily snapshots: 33 days
  • Daily snapshots are created at 00:00 UTC.
| +| **Custom Retention Mode** |
  • PITR
  • Daily backup snapshots
| You can set the retention period from 3 to 33 days. PITR and daily snapshots use the configured retention period. | + + + +PITR lets you restore data to any point in time within the retention period. A snapshot lets you restore data from a specific hourly or daily snapshot that is still within the retention period. + +### Configure automatic backups + +1. On the [**My TiDB**](https://tidbcloud.com/tidbs) page, click the name of your target {{{ .premium }}} or {{{ .byoc }}} instance. + +2. In the left navigation pane, click **Data** > **Backup**. + +3. In the upper-right corner, click **...**, and then click **Backup Settings**. + +4. Select an automatic backup mode: + + - **Standard Bundle Mode** uses predefined settings for PITR, hourly snapshots, and daily snapshots. + - **Custom Retention Mode** lets you specify the automatic backup retention period and daily backup time. + +5. If you select **Custom Retention Mode**, configure the following settings. Otherwise, skip this step. + + - **Backup Retention**: select a retention period from 3 to 33 days. The default value is 7 days. + - **Daily Backup Time**: select the time of day for the daily snapshot. The time zone is displayed next to the setting. + +6. Review the **Overview** section, and then click **Save**. + + The overview shows the backup types enabled by the selected backup mode, the corresponding retention periods, and the available restore options. + + + +> **Note:** +> +> If you [switch between backup modes](#switch-between-automatic-backup-modes) or reduce the retention period, TiDB Cloud might permanently delete existing automatic backups that are older than the new retention period. This action cannot be undone. + + + + + +> **Note:** +> +> - Custom Retention Mode pricing is based on snapshot size and retention duration. PITR is temporarily free during the public preview period. See [TiDB Cloud pricing](https://www.pingcap.com/tidb-cloud-premium-pricing-details) for more information. +> - If you [switch between backup modes](#switch-between-automatic-backup-modes) or reduce the retention period, TiDB Cloud might permanently delete existing automatic backups that are older than the new retention period. This action cannot be undone. + + + +### Switch between automatic backup modes + +To switch between **Standard Bundle Mode** and **Custom Retention Mode**, take the following steps: + +1. Navigate to the [**Backup**](#view-the-backup-page) page of your instance. +2. In the upper-right corner, click **...**, and then click **Backup Settings**. +3. In the displayed dialog, select a new mode. + + - If you switch to **Custom Retention Mode**, you need to configure the backup retention period and daily backup time. + - If you switch to **Standard Bundle Mode**, the retention periods and daily backup time are reset to the standard bundle defaults. + +4. Review the retention settings in the **Overview** section, and then click **Save**. + + + +After you save the changes, future automatic backups are billed according to the pricing model of the selected mode. + + + +If the new retention period is shorter than the current retention period, the confirmation dialog lists the automatic backups that are older than the new retention period and will be permanently deleted. Confirm the operation only after verifying that you no longer need those backups. + +### Backup protection + +To help prevent data loss and preserve a recovery point, TiDB Cloud protects **the latest successful automatic backup** of an instance until its retention period expires. Therefore, you cannot manually delete this protected latest backup, even after the instance is deleted. If you attempt to delete it, the console displays a message explaining that the backup is protected and cannot be deleted before it expires. + +### Delete backup files + +To delete an existing backup file for your {{{ .premium }}} or {{{ .byoc }}} instance, perform the following steps: + +1. Navigate to the [**Backup**](#view-the-backup-page) page of your instance. + +2. Locate the corresponding backup file you want to delete, and click **...** > **Delete** in the **Action** column. + > **Note:** - > - > Even if the current provisioned vCPU is below the Pool vCPU Limit, restoring an instance might cause the total provisioned vCPU to exceed the limit. This might constrain resource scaling and degrade the performance of all instances in the resource pool. Before restoring the instance, make sure that the resource pool has sufficient vCPU capacity. If necessary, increase or turn off the Pool vCPU Limit, or select another resource pool. - - - - > **Note:** - > - > The new instance uses the same cloud provider and region as the backup by default. - -6. Click **Restore** to start the restore process. - - When the restore process starts, the instance status first changes to **Creating**. After the creation is complete, it changes to **Restoring**. The instance remains unavailable until the restore finishes and the status changes to **Available**. - -### Restore from Recycle Bin - -To restore a deleted {{{ .premium }}} or {{{ .byoc }}} instance from the Recycle Bin, take the following steps: - -1. In the [TiDB Cloud console](https://tidbcloud.com), navigate to the [**My TiDB**](https://tidbcloud.com/tidbs) page of your organization, click **...** in the upper-right corner, and then click **Recycle Bin**. - - > **Tip:** - > - > If you are in multiple organizations, use the combo box in the upper-left corner to switch to your target organization first. - -2. On the **Recycle Bin** page, click the **Premium****BYOC** tab to go to the recycle bin of {{{ .premium }}}{{{ .byoc }}} instances. - -3. Locate the {{{ .premium }}}{{{ .byoc }}} instance you want to restore, and then click the **>** button to expand the available backups of the instance. - -4. In the row of your desired backup, click **...**, and then select **Restore**. - -5. On the **Restore** page, follow the same steps as [Restore to a new instance](#restore-to-a-new-instance) to restore the backup to a new instance. - - - -### Restore backups from a different plan type - -Currently, you can only restore backups from a {{{ .dedicated }}} cluster hosted on AWS to a new {{{ .premium }}} instance. - -To restore a backup generated by a {{{ .dedicated }}} cluster, follow these steps: - -1. Log in to the [TiDB Cloud console](https://tidbcloud.com), and then navigate to the [**My TiDB**](https://tidbcloud.com/tidbs) page. In the upper-right corner, click **...**, and then click **Restore from Another Plan**. - -2. On the **Select Backup** page, select the project that contains the target {{{ .dedicated }}} cluster. Select the {{{ .dedicated }}} cluster, select the backup snapshot that you want to restore, and then click **Next**. - - > **Note:** - > - > - Ensure that the {{{ .dedicated }}} cluster that contains the backup snapshot is in either the **Active** or **Deleted** status within the selected project. - > - The snapshot must be located in a region that {{{ .premium }}} supports. If the region is not supported, contact [TiDB Cloud Support](/tidb-cloud/tidb-cloud-support.md) to open a new region for {{{ .premium }}}, or select another backup snapshot. - -3. On the **Restore** page, follow the same steps as [Restore to a new instance](#restore-to-a-new-instance) to restore the backup to a new instance. - - - -### Restore backups from cloud storage - - - -{{{ .premium }}} supports restoring backups from cloud storage (such as Amazon S3 and Alibaba Cloud Object Storage Service (OSS)) to a new instance. This feature is compatible with backups generated from {{{ .dedicated }}} clusters or TiDB Self-Managed clusters. - - - - - -{{{ .premium }}} and {{{ .byoc }}} support restoring backups from cloud storage (such as Amazon S3) to a new instance. This feature is compatible with backups generated from {{{ .dedicated }}} clusters or TiDB Self-Managed clusters. - - - - - -> **Note:** -> -> - Currently, only backups located in **Amazon S3** and **Alibaba Cloud OSS** are supported for restore. -> - You can restore backups only to a new instance hosted by the same cloud provider as your storage bucket. -> - If the instance and the storage bucket are located in different regions, additional cross-region data transfer fees might apply. - - - - - -> **Note:** -> -> - Currently, only backups located in **Amazon S3** are supported for restore. -> - You can restore backups only to a new instance hosted by the same cloud provider as your storage bucket. -> - If the instance and the storage bucket are located in different regions, additional cross-region data transfer fees might apply. - - - -#### Steps - -Before you begin, ensure that you have an access key and secret key with sufficient permissions to access the backup files. - -To restore backups from cloud storage, do the following: - -1. Log in to the [TiDB Cloud console](https://tidbcloud.com), and then navigate to the [**My TiDB**](https://tidbcloud.com/tidbs) page. In the upper-right corner, click **...** , and then click **Restore from Cloud Storage**. - -2. On the **Select Backup Storage Location** page, provide the following information: - - - - - **Cloud Provider**: select the cloud provider where your backup files are stored. - - **Region**: if your cloud provider is Alibaba Cloud OSS, select a region. - - **Backup Files URI**: enter the URI of the top-level folder that contains your backup files. - - **Access Key ID**: enter your access key ID. - - **Access Key Secret**: enter your access key secret. - - - - - - - **Cloud Provider**: select the cloud provider where your backup files are stored. - - **Backup Files URI**: enter the URI of the top-level folder that contains your backup files. - - **Access Key ID**: enter your access key ID. - - **Access Key Secret**: enter your access key secret. - - - - > **Tip:** - > - > To create an access key for your storage bucket, see [Configure Amazon S3 access using an AWS access key](#configure-amazon-s3-access-using-an-aws-access-key) and [Configure Alibaba Cloud OSS access](#configure-alibaba-cloud-oss-access). - -3. Click **Verify Backup and Next**. - -4. If the verification is successful, the **Restore to a New Instance** page appears. Review the backup information displayed at the top of the page, and then follow the steps in [Create a {{{ .premium }}} Instance](/tidb-cloud/premium/create-tidb-instance-premium.md)[Create a {{{ .byoc }}} Instance](/tidb-cloud/byoc/create-tidb-instance-byoc.md) to restore the backup to a new instance. - - - - For {{{ .byoc }}}, select an active resource pool that matches the target cloud provider and region. The restored instance inherits the high availability mode of the selected resource pool. You can restore the same backup to a Zonal or Regional resource pool if the resource pool meets the restore requirements. If no suitable resource pool is available, an `Organization Owner` can create one before restoring the instance. Other roles cannot create resource pools. For more information, see [Create a Resource Pool](/tidb-cloud/byoc/create-resource-pool-byoc.md). - - If the selected resource pool has a Pool vCPU Limit and its current provisioned vCPU is greater than or equal to the limit, TiDB Cloud displays a warning and you cannot restore the instance to that resource pool. To continue, go to the Resource Pool details page to increase or turn off the Pool vCPU Limit, or select another resource pool. - + > + > TiDB Cloud protects the **latest successful automatic backup** of your instance to help prevent data loss. If you attempt to delete it, the console displays a message explaining that the backup is protected and cannot be deleted before it expires. + > If you have the `Organization Owner` or `Project Owner` role in TiDB Cloud, you can delete an automatic backup other than the latest successful one, or delete a manual backup. + +## Manual backups + + + +In addition to automatic backups, {{{ .premium }}} supports manual backups. A manual backup provides a controlled, guaranteed restore point. It is highly recommended that you create a manual backup before you perform high-risk operations such as system upgrades, critical data deletion, or irreversible schema or configuration changes. + + + + + +In addition to automatic backups, {{{ .premium }}} and {{{ .byoc }}} support manual backups. A manual backup provides a controlled, guaranteed restore point. It is highly recommended that you create a manual backup before you perform high-risk operations such as system upgrades, critical data deletion, or irreversible schema or configuration changes. + + + +### Key characteristics + +- **Retention and deletion**: unlike automatic backups, manual backups are not automatically deleted based on retention policies. They are retained until you explicitly delete them. If you delete the instance, its manual backups move to the recycle bin and remain there until you manually delete them. + +- **Storage location**: manual backups are stored in cloud storage managed by TiDB. + +- **Cost**: manual backups incur additional charges because they are retained until you delete them. + +- **Limitations**: manual backups do not support point-in-time recovery (PITR) or partial backups (for example, table-level or database-level backups). You cannot restore a manual backup to an existing instance. Each restore operation creates a new instance. + +- **Permissions**: both `Organization Owner` and `Instance Manager` can create manual backups. Only `Organization Owner` can restore system-managed manual backups. + +### Create a manual backup + +1. Navigate to the [**Backup**](#view-the-backup-page) page of your instance. + +2. In the upper-right corner, click **...**, and then click **Manual Backup**. + +3. Confirm the operation. The backup is stored in TiDB Cloud and will appear in the **Backup List**. + +You can restore a manual backup directly in the TiDB Cloud console without providing external storage credentials. + +## Restore + +TiDB Cloud provides restore functionality to help recover data in case of accidental loss or corruption. You can restore from backups of active instances or from deleted instances in the Recycle Bin. + +### Restore mode + +TiDB Cloud supports snapshot restore and point-in-time restore for your instance. + +- **Snapshot Restore**: restores your instance from a specific backup snapshot. You can use this method to restore both automatic and manual backups. In the **Backup List**, manual backups are labeled with the **Manual** type and a **Permanent** expiration status. + +- **Point-in-Time Restore**: restores your instance to a specific point in time. + + - Premium or BYOC instances: can be restored to any time within the last 7 days, but not earlier than the instance creation time or later than one minute before the current time. Note that PITR is not supported for manual backups. + +### Restore destination + +TiDB Cloud supports restoring data to a new instance. + +### Restore to a new {{{ .premium }}} instance {#restore-to-a-new-instance} + +To restore your data to a new {{{ .premium }}} or {{{ .byoc }}} instance, take the following steps: + +1. Navigate to the [**Backup**](#view-the-backup-page) page of your instance. + +2. Click **Restore**. + +3. On the **Select Backup** page, choose the **Restore Mode** you want to use. You can restore from a specific backup snapshot or restore to a specific point in time. + + +
+ + To restore from a selected backup snapshot, take the following steps: + + 1. Click **Snapshot Restore**. + 2. Select the backup snapshot you want to restore from. + +
+
+ + To restore to a specific point in time for a Premium or BYOC instance, take the following steps: + + 1. Click **Point-in-Time Restore**. + 2. Select the date and time you want to restore to. + +
+ + +4. Click **Next** to proceed to the **Restore to a New Instance** page. + +5. Configure your new {{{ .premium }}} or {{{ .byoc }}} instance for restoration. Follow the steps in [Create a {{{ .premium }}} Instance](/tidb-cloud/premium/create-tidb-instance-premium.md)[Create a {{{ .byoc }}} Instance](/tidb-cloud/byoc/create-tidb-instance-byoc.md). + + + + For {{{ .byoc }}}, select an active resource pool in the same cloud provider and region as the backup. The restored instance inherits the high availability mode of the selected resource pool. You can restore the same backup to a Zonal or Regional resource pool. If no suitable resource pool is available, an `Organization Owner` can create one before restoring the instance. Other roles cannot create resource pools. For more information, see [Create a Resource Pool](/tidb-cloud/byoc/create-resource-pool-byoc.md). + + If the selected resource pool has a Pool vCPU Limit and its current provisioned vCPU is greater than or equal to the limit, TiDB Cloud displays a warning and you cannot restore the instance to that resource pool. To continue, go to the Resource Pool details page to increase or turn off the Pool vCPU Limit, or select another resource pool. + > **Note:** - > + > + > Even if the current provisioned vCPU is below the Pool vCPU Limit, restoring an instance might cause the total provisioned vCPU to exceed the limit. This might constrain resource scaling and degrade the performance of all instances in the resource pool. Before restoring the instance, make sure that the resource pool has sufficient vCPU capacity. If necessary, increase or turn off the Pool vCPU Limit, or select another resource pool. + + + + > **Note:** + > + > The new instance uses the same cloud provider and region as the backup by default. + +6. Click **Restore** to start the restore process. + + When the restore process starts, the instance status first changes to **Creating**. After the creation is complete, it changes to **Restoring**. The instance remains unavailable until the restore finishes and the status changes to **Available**. + +### Restore from Recycle Bin + +To restore a deleted {{{ .premium }}} or {{{ .byoc }}} instance from the Recycle Bin, take the following steps: + +1. In the [TiDB Cloud console](https://tidbcloud.com), navigate to the [**My TiDB**](https://tidbcloud.com/tidbs) page of your organization, click **...** in the upper-right corner, and then click **Recycle Bin**. + + > **Tip:** + > + > If you are in multiple organizations, use the combo box in the upper-left corner to switch to your target organization first. + +2. On the **Recycle Bin** page, click the **Premium****BYOC** tab to go to the recycle bin of {{{ .premium }}}{{{ .byoc }}} instances. + +3. Locate the {{{ .premium }}}{{{ .byoc }}} instance you want to restore, and then click the **>** button to expand the available backups of the instance. + +4. In the row of your desired backup, click **...**, and then select **Restore**. + +5. On the **Restore** page, follow the same steps as [Restore to a new instance](#restore-to-a-new-instance) to restore the backup to a new instance. + + + +### Restore backups from a different plan type + +Currently, you can only restore backups from a {{{ .dedicated }}} cluster hosted on AWS to a new {{{ .premium }}} instance. + +To restore a backup generated by a {{{ .dedicated }}} cluster, follow these steps: + +1. Log in to the [TiDB Cloud console](https://tidbcloud.com), and then navigate to the [**My TiDB**](https://tidbcloud.com/tidbs) page. In the upper-right corner, click **...**, and then click **Restore from Another Plan**. + +2. On the **Select Backup** page, select the project that contains the target {{{ .dedicated }}} cluster. Select the {{{ .dedicated }}} cluster, select the backup snapshot that you want to restore, and then click **Next**. + + > **Note:** + > + > - Ensure that the {{{ .dedicated }}} cluster that contains the backup snapshot is in either the **Active** or **Deleted** status within the selected project. + > - The snapshot must be located in a region that {{{ .premium }}} supports. If the region is not supported, contact [TiDB Cloud Support](/tidb-cloud/tidb-cloud-support.md) to open a new region for {{{ .premium }}}, or select another backup snapshot. + +3. On the **Restore** page, follow the same steps as [Restore to a new instance](#restore-to-a-new-instance) to restore the backup to a new instance. + + + +### Restore backups from cloud storage + + + +{{{ .premium }}} supports restoring backups from cloud storage (such as Amazon S3 and Alibaba Cloud Object Storage Service (OSS)) to a new instance. This feature is compatible with backups generated from {{{ .dedicated }}} clusters or TiDB Self-Managed clusters. + + + + + +{{{ .premium }}} and {{{ .byoc }}} support restoring backups from cloud storage (such as Amazon S3) to a new instance. This feature is compatible with backups generated from {{{ .dedicated }}} clusters or TiDB Self-Managed clusters. + + + + + +> **Note:** +> +> - Currently, only backups located in **Amazon S3** and **Alibaba Cloud OSS** are supported for restore. +> - You can restore backups only to a new instance hosted by the same cloud provider as your storage bucket. +> - If the instance and the storage bucket are located in different regions, additional cross-region data transfer fees might apply. + + + + + +> **Note:** +> +> - Currently, only backups located in **Amazon S3** are supported for restore. +> - You can restore backups only to a new instance hosted by the same cloud provider as your storage bucket. +> - If the instance and the storage bucket are located in different regions, additional cross-region data transfer fees might apply. + + + +#### Steps + +Before you begin, ensure that you have an access key and secret key with sufficient permissions to access the backup files. + +To restore backups from cloud storage, do the following: + +1. Log in to the [TiDB Cloud console](https://tidbcloud.com), and then navigate to the [**My TiDB**](https://tidbcloud.com/tidbs) page. In the upper-right corner, click **...** , and then click **Restore from Cloud Storage**. + +2. On the **Select Backup Storage Location** page, provide the following information: + + + + - **Cloud Provider**: select the cloud provider where your backup files are stored. + - **Region**: if your cloud provider is Alibaba Cloud OSS, select a region. + - **Backup Files URI**: enter the URI of the top-level folder that contains your backup files. + - **Access Key ID**: enter your access key ID. + - **Access Key Secret**: enter your access key secret. + + + + + + - **Cloud Provider**: select the cloud provider where your backup files are stored. + - **Backup Files URI**: enter the URI of the top-level folder that contains your backup files. + - **Access Key ID**: enter your access key ID. + - **Access Key Secret**: enter your access key secret. + + + + > **Tip:** + > + > To create an access key for your storage bucket, see [Configure Amazon S3 access using an AWS access key](#configure-amazon-s3-access-using-an-aws-access-key) and [Configure Alibaba Cloud OSS access](#configure-alibaba-cloud-oss-access). + +3. Click **Verify Backup and Next**. + +4. If the verification is successful, the **Restore to a New Instance** page appears. Review the backup information displayed at the top of the page, and then follow the steps in [Create a {{{ .premium }}} Instance](/tidb-cloud/premium/create-tidb-instance-premium.md)[Create a {{{ .byoc }}} Instance](/tidb-cloud/byoc/create-tidb-instance-byoc.md) to restore the backup to a new instance. + + + + For {{{ .byoc }}}, select an active resource pool that matches the target cloud provider and region. The restored instance inherits the high availability mode of the selected resource pool. You can restore the same backup to a Zonal or Regional resource pool. If no suitable resource pool is available, an `Organization Owner` can create one before restoring the instance. Other roles cannot create resource pools. For more information, see [Create a Resource Pool](/tidb-cloud/byoc/create-resource-pool-byoc.md). + + If the selected resource pool has a Pool vCPU Limit and its current provisioned vCPU is greater than or equal to the limit, TiDB Cloud displays a warning and you cannot restore the instance to that resource pool. To continue, go to the Resource Pool details page to increase or turn off the Pool vCPU Limit, or select another resource pool. + + > **Note:** + > > Even if the current provisioned vCPU is below the Pool vCPU Limit, restoring an instance might cause the total provisioned vCPU to exceed the limit. This might restrict resource scaling and affect the performance of all instances in the resource pool. Before restoring the instance, make sure that the resource pool has sufficient vCPU capacity. If necessary, increase or turn off the Pool vCPU Limit, or select another resource pool. - - - - If the backup information is incorrect, click **Previous** to return to the previous page, and then enter the correct information. - -5. Click **Restore** to restore the backup. - -## References - -This section describes how to configure access for Amazon S3 and Alibaba Cloud OSS. - -### Configure Amazon S3 access using an AWS access key - -It is recommended that you use an IAM user, rather than the AWS account root user, to create an access key. - -Take the following steps to configure an access key: - -1. Create an IAM user and access key. - - 1. Create an IAM user. For more information, see [Create an IAM user in your AWS account](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_create.html#id_users_create_console). - 2. Sign in to the [IAM console](https://console.aws.amazon.com/iam) using your AWS account ID or account alias, and your IAM user name and password. - 3. Create an access key. For more information, see [Manage access keys for IAM users](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#Using_CreateAccessKey). - -2. Grant permissions to the IAM user. - - Create a policy with only the permissions required for your task and attach it to the IAM user. To restore data to a {{{ .premium }}} or {{{ .byoc }}} instance, grant the `s3:GetObject`, `s3:GetBucketLocation`, and `s3:ListBucket` permissions. - - The following is an example policy that allows TiDB Cloud to restore data from a specific folder in your Amazon S3 bucket. - - ```json - { - "Version": "2012-10-17", - "Statement": [ - { - "Sid": "AllowGetBucketLocation", - "Effect": "Allow", - "Action": "s3:GetBucketLocation", - "Resource": "arn:aws:s3:::" - }, - { - "Sid": "AllowListPrefix", - "Effect": "Allow", - "Action": "s3:ListBucket", - "Resource": "arn:aws:s3:::", - "Condition": { - "StringLike": { - "s3:prefix": "/*" - } - } - }, - { - "Sid": "AllowReadObjectsInPrefix", - "Effect": "Allow", - "Action": "s3:GetObject", - "Resource": "arn:aws:s3::://*" - } - ] - } - ``` - - In the preceding policy, replace `` and `` with your actual bucket name and backup directory. This configuration follows the principle of least privilege by limiting access to only the necessary backup files. - -> **Note:** -> -> TiDB Cloud does not store your access keys. To maintain security, [delete the access key](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#Using_CreateAccessKey) after the import or export task is complete. - - - -### Configure Alibaba Cloud OSS access - -To grant TiDB Cloud access to your Alibaba Cloud OSS bucket, you need to create an AccessKey pair for the bucket. - -Take the following steps to configure an AccessKey pair: - -1. Create a RAM user and obtain the AccessKey pair. For more information, see [Create a RAM user](https://www.alibabacloud.com/help/en/ram/user-guide/create-a-ram-user). - - In the **Access Mode** section, select **Using permanent AccessKey to access**. - -2. Create a custom policy with the required permissions. For more information, see [Create custom policies](https://www.alibabacloud.com/help/en/ram/user-guide/create-a-custom-policy). - - - In the **Effect** section, select **Allow**. - - In the **Service** section, select **Object Storage Service**. - - In the **Action** section, select the required permissions. To restore a backup to a {{{ .premium }}} instance, grant the `oss:ListObjects` and `oss:GetObject` permissions. - - > **Tip:** - > - > To enhance security for restore operations, you can restrict access to the specific folder (`oss:Prefix`) where your backup files are stored rather than granting access to the entire bucket. - - The following JSON example shows a policy for a restore task. This policy restricts access to a specific bucket and backup folder. - - ```json - { - "Version": "1", - "Statement": [ - { - "Effect": "Allow", - "Action": "oss:ListObjects", - "Resource": "acs:oss:*:*:", - "Condition": { - "StringLike": { - "oss:Prefix": "/*" - } - } - }, - { - "Effect": "Allow", - "Action": "oss:GetObject", - "Resource": "acs:oss:*:*://*" - } - ] - } - ``` - - - In the **Resource** section, select the bucket and the specific objects in the bucket. - -3. Attach the custom policies to the RAM user. - - For more information, see [Grant permissions to a RAM user](https://www.alibabacloud.com/help/en/ram/user-guide/grant-permissions-to-the-ram-user). - - + + + + If the backup information is incorrect, click **Previous** to return to the previous page, and then enter the correct information. + +5. Click **Restore** to restore the backup. + +## References + +This section describes how to configure access for Amazon S3 and Alibaba Cloud OSS. + +### Configure Amazon S3 access using an AWS access key + +It is recommended that you use an IAM user, rather than the AWS account root user, to create an access key. + +Take the following steps to configure an access key: + +1. Create an IAM user and access key. + + 1. Create an IAM user. For more information, see [Create an IAM user in your AWS account](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_create.html#id_users_create_console). + 2. Sign in to the [IAM console](https://console.aws.amazon.com/iam) using your AWS account ID or account alias, and your IAM user name and password. + 3. Create an access key. For more information, see [Manage access keys for IAM users](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#Using_CreateAccessKey). + +2. Grant permissions to the IAM user. + + Create a policy with only the permissions required for your task and attach it to the IAM user. To restore data to a {{{ .premium }}} or {{{ .byoc }}} instance, grant the `s3:GetObject`, `s3:GetBucketLocation`, and `s3:ListBucket` permissions. + + The following is an example policy that allows TiDB Cloud to restore data from a specific folder in your Amazon S3 bucket. + + ```json + { + "Version": "2012-10-17", + "Statement": [ + { + "Sid": "AllowGetBucketLocation", + "Effect": "Allow", + "Action": "s3:GetBucketLocation", + "Resource": "arn:aws:s3:::" + }, + { + "Sid": "AllowListPrefix", + "Effect": "Allow", + "Action": "s3:ListBucket", + "Resource": "arn:aws:s3:::", + "Condition": { + "StringLike": { + "s3:prefix": "/*" + } + } + }, + { + "Sid": "AllowReadObjectsInPrefix", + "Effect": "Allow", + "Action": "s3:GetObject", + "Resource": "arn:aws:s3::://*" + } + ] + } + ``` + + In the preceding policy, replace `` and `` with your actual bucket name and backup directory. This configuration follows the principle of least privilege by limiting access to only the necessary backup files. + +> **Note:** +> +> TiDB Cloud does not store your access keys. To maintain security, [delete the access key](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#Using_CreateAccessKey) after the import or export task is complete. + + + +### Configure Alibaba Cloud OSS access + +To grant TiDB Cloud access to your Alibaba Cloud OSS bucket, you need to create an AccessKey pair for the bucket. + +Take the following steps to configure an AccessKey pair: + +1. Create a RAM user and obtain the AccessKey pair. For more information, see [Create a RAM user](https://www.alibabacloud.com/help/en/ram/user-guide/create-a-ram-user). + + In the **Access Mode** section, select **Using permanent AccessKey to access**. + +2. Create a custom policy with the required permissions. For more information, see [Create custom policies](https://www.alibabacloud.com/help/en/ram/user-guide/create-a-custom-policy). + + - In the **Effect** section, select **Allow**. + - In the **Service** section, select **Object Storage Service**. + - In the **Action** section, select the required permissions. To restore a backup to a {{{ .premium }}} instance, grant the `oss:ListObjects` and `oss:GetObject` permissions. + + > **Tip:** + > + > To enhance security for restore operations, you can restrict access to the specific folder (`oss:Prefix`) where your backup files are stored rather than granting access to the entire bucket. + + The following JSON example shows a policy for a restore task. This policy restricts access to a specific bucket and backup folder. + + ```json + { + "Version": "1", + "Statement": [ + { + "Effect": "Allow", + "Action": "oss:ListObjects", + "Resource": "acs:oss:*:*:", + "Condition": { + "StringLike": { + "oss:Prefix": "/*" + } + } + }, + { + "Effect": "Allow", + "Action": "oss:GetObject", + "Resource": "acs:oss:*:*://*" + } + ] + } + ``` + + - In the **Resource** section, select the bucket and the specific objects in the bucket. + +3. Attach the custom policies to the RAM user. + + For more information, see [Grant permissions to a RAM user](https://www.alibabacloud.com/help/en/ram/user-guide/grant-permissions-to-the-ram-user). + + From f11a231938caef17f40c8985cc62732a54c1c6a1 Mon Sep 17 00:00:00 2001 From: qiancai Date: Tue, 25 Aug 2026 17:45:45 +0800 Subject: [PATCH 17/20] docs: normalize line endings for premium backup guide --- .../premium/backup-and-restore-premium.md | 1002 ++++++++--------- 1 file changed, 501 insertions(+), 501 deletions(-) diff --git a/tidb-cloud/premium/backup-and-restore-premium.md b/tidb-cloud/premium/backup-and-restore-premium.md index 614a51cf5a1f4..a38d9199cb860 100644 --- a/tidb-cloud/premium/backup-and-restore-premium.md +++ b/tidb-cloud/premium/backup-and-restore-premium.md @@ -1,501 +1,501 @@ ---- -title: Back Up and Restore {{{ .premium }}} Data -summary: Learn how to back up and restore your {{{ .premium }}} instances. -aliases: ['/tidbcloud/restore-deleted-tidb-cluster'] ---- - -# Back Up and Restore {{{ .premium }}} Data - - - -This document describes how to back up and restore your data on {{{ .premium }}} instances. {{{ .premium }}} supports both automatic backups and manual backups, and lets you restore backup data to a new instance as needed. - - - - - -This document describes how to back up and restore your data on {{{ .premium }}} or {{{ .byoc }}} instances. {{{ .premium }}} and {{{ .byoc }}} support both automatic backups and manual backups, and let you restore backup data to a new instance as needed. - - - -Backup files can originate from the following sources: - -- Active {{{ .premium }}} or {{{ .byoc }}} instances -- The Recycle Bin for backups from deleted {{{ .premium }}} or {{{ .byoc }}} instances - -> **Tip:** -> -> - To learn how to back up and restore data on {{{ .dedicated }}} clusters, see [Back Up and Restore {{{ .dedicated }}} Data](/tidb-cloud/backup-and-restore.md). -> - To learn how to back up and restore data on {{{ .starter }}} or {{{ .essential }}} instances, see [Back Up and Restore {{{ .starter }}} or Essential Data](/tidb-cloud/backup-and-restore-serverless.md). - -## View the Backup page - -1. On the [**My TiDB**](https://tidbcloud.com/tidbs) page, click the name of your target {{{ .premium }}} or {{{ .byoc }}} instance to go to its overview page. - - > **Tip:** - > - > If you are in multiple organizations, use the combo box in the upper-left corner to switch to your target organization first. - -2. In the left navigation pane, click **Data** > **Backup**. - -## Automatic backups - - - -{{{ .premium }}} provides enhanced automatic backup capabilities for production environments. It combines high-frequency snapshots with log backups to ensure data reliability. - - - - - -{{{ .premium }}} and {{{ .byoc }}} provide enhanced automatic backup capabilities for production environments. They combine high-frequency snapshots with log backups to ensure data reliability. - - - -### Automatic backup modes - -You can choose an automatic backup mode in **Backup Settings**. The available backup types, retention periods, and pricing model depend on the selected mode. - - - -| Backup mode | Supported backup types | Retention and restore options | Pricing model | -| --- | --- | --- | --- | -| **Standard Bundle Mode** |
  • PITR
  • Hourly backup snapshots
  • Daily backup snapshots
|
  • PITR: 7 days
  • Hourly snapshots: 7 days
  • Daily snapshots: 33 days
  • Daily snapshots are created at 00:00 UTC.
| Based on incremental data volume. | -| **Custom Retention Mode** |
  • PITR
  • Daily backup snapshots
| You can set the retention period from 3 to 33 days. PITR and daily snapshots use the configured retention period. | Based on snapshot size multiplied by retention duration. Each backup is billed as a separate object. | - - - - - -| Backup mode | Supported backup types | Retention and restore options | -| --- | --- | --- | -| **Standard Bundle Mode** |
  • PITR
  • Hourly backup snapshots
  • Daily backup snapshots
|
  • PITR: 7 days
  • Hourly snapshots: 7 days
  • Daily snapshots: 33 days
  • Daily snapshots are created at 00:00 UTC.
| -| **Custom Retention Mode** |
  • PITR
  • Daily backup snapshots
| You can set the retention period from 3 to 33 days. PITR and daily snapshots use the configured retention period. | - - - -PITR lets you restore data to any point in time within the retention period. A snapshot lets you restore data from a specific hourly or daily snapshot that is still within the retention period. - -### Configure automatic backups - -1. On the [**My TiDB**](https://tidbcloud.com/tidbs) page, click the name of your target {{{ .premium }}} or {{{ .byoc }}} instance. - -2. In the left navigation pane, click **Data** > **Backup**. - -3. In the upper-right corner, click **...**, and then click **Backup Settings**. - -4. Select an automatic backup mode: - - - **Standard Bundle Mode** uses predefined settings for PITR, hourly snapshots, and daily snapshots. - - **Custom Retention Mode** lets you specify the automatic backup retention period and daily backup time. - -5. If you select **Custom Retention Mode**, configure the following settings. Otherwise, skip this step. - - - **Backup Retention**: select a retention period from 3 to 33 days. The default value is 7 days. - - **Daily Backup Time**: select the time of day for the daily snapshot. The time zone is displayed next to the setting. - -6. Review the **Overview** section, and then click **Save**. - - The overview shows the backup types enabled by the selected backup mode, the corresponding retention periods, and the available restore options. - - - -> **Note:** -> -> If you [switch between backup modes](#switch-between-automatic-backup-modes) or reduce the retention period, TiDB Cloud might permanently delete existing automatic backups that are older than the new retention period. This action cannot be undone. - - - - - -> **Note:** -> -> - Custom Retention Mode pricing is based on snapshot size and retention duration. PITR is temporarily free during the public preview period. See [TiDB Cloud pricing](https://www.pingcap.com/tidb-cloud-premium-pricing-details) for more information. -> - If you [switch between backup modes](#switch-between-automatic-backup-modes) or reduce the retention period, TiDB Cloud might permanently delete existing automatic backups that are older than the new retention period. This action cannot be undone. - - - -### Switch between automatic backup modes - -To switch between **Standard Bundle Mode** and **Custom Retention Mode**, take the following steps: - -1. Navigate to the [**Backup**](#view-the-backup-page) page of your instance. -2. In the upper-right corner, click **...**, and then click **Backup Settings**. -3. In the displayed dialog, select a new mode. - - - If you switch to **Custom Retention Mode**, you need to configure the backup retention period and daily backup time. - - If you switch to **Standard Bundle Mode**, the retention periods and daily backup time are reset to the standard bundle defaults. - -4. Review the retention settings in the **Overview** section, and then click **Save**. - - - -After you save the changes, future automatic backups are billed according to the pricing model of the selected mode. - - - -If the new retention period is shorter than the current retention period, the confirmation dialog lists the automatic backups that are older than the new retention period and will be permanently deleted. Confirm the operation only after verifying that you no longer need those backups. - -### Backup protection - -To help prevent data loss and preserve a recovery point, TiDB Cloud protects **the latest successful automatic backup** of an instance until its retention period expires. Therefore, you cannot manually delete this protected latest backup, even after the instance is deleted. If you attempt to delete it, the console displays a message explaining that the backup is protected and cannot be deleted before it expires. - -### Delete backup files - -To delete an existing backup file for your {{{ .premium }}} or {{{ .byoc }}} instance, perform the following steps: - -1. Navigate to the [**Backup**](#view-the-backup-page) page of your instance. - -2. Locate the corresponding backup file you want to delete, and click **...** > **Delete** in the **Action** column. - - > **Note:** - > - > TiDB Cloud protects the **latest successful automatic backup** of your instance to help prevent data loss. If you attempt to delete it, the console displays a message explaining that the backup is protected and cannot be deleted before it expires. - > If you have the `Organization Owner` or `Project Owner` role in TiDB Cloud, you can delete an automatic backup other than the latest successful one, or delete a manual backup. - -## Manual backups - - - -In addition to automatic backups, {{{ .premium }}} supports manual backups. A manual backup provides a controlled, guaranteed restore point. It is highly recommended that you create a manual backup before you perform high-risk operations such as system upgrades, critical data deletion, or irreversible schema or configuration changes. - - - - - -In addition to automatic backups, {{{ .premium }}} and {{{ .byoc }}} support manual backups. A manual backup provides a controlled, guaranteed restore point. It is highly recommended that you create a manual backup before you perform high-risk operations such as system upgrades, critical data deletion, or irreversible schema or configuration changes. - - - -### Key characteristics - -- **Retention and deletion**: unlike automatic backups, manual backups are not automatically deleted based on retention policies. They are retained until you explicitly delete them. If you delete the instance, its manual backups move to the recycle bin and remain there until you manually delete them. - -- **Storage location**: manual backups are stored in cloud storage managed by TiDB. - -- **Cost**: manual backups incur additional charges because they are retained until you delete them. - -- **Limitations**: manual backups do not support point-in-time recovery (PITR) or partial backups (for example, table-level or database-level backups). You cannot restore a manual backup to an existing instance. Each restore operation creates a new instance. - -- **Permissions**: both `Organization Owner` and `Instance Manager` can create manual backups. Only `Organization Owner` can restore system-managed manual backups. - -### Create a manual backup - -1. Navigate to the [**Backup**](#view-the-backup-page) page of your instance. - -2. In the upper-right corner, click **...**, and then click **Manual Backup**. - -3. Confirm the operation. The backup is stored in TiDB Cloud and will appear in the **Backup List**. - -You can restore a manual backup directly in the TiDB Cloud console without providing external storage credentials. - -## Restore - -TiDB Cloud provides restore functionality to help recover data in case of accidental loss or corruption. You can restore from backups of active instances or from deleted instances in the Recycle Bin. - -### Restore mode - -TiDB Cloud supports snapshot restore and point-in-time restore for your instance. - -- **Snapshot Restore**: restores your instance from a specific backup snapshot. You can use this method to restore both automatic and manual backups. In the **Backup List**, manual backups are labeled with the **Manual** type and a **Permanent** expiration status. - -- **Point-in-Time Restore**: restores your instance to a specific point in time. - - - Premium or BYOC instances: can be restored to any time within the last 7 days, but not earlier than the instance creation time or later than one minute before the current time. Note that PITR is not supported for manual backups. - -### Restore destination - -TiDB Cloud supports restoring data to a new instance. - -### Restore to a new {{{ .premium }}} instance {#restore-to-a-new-instance} - -To restore your data to a new {{{ .premium }}} or {{{ .byoc }}} instance, take the following steps: - -1. Navigate to the [**Backup**](#view-the-backup-page) page of your instance. - -2. Click **Restore**. - -3. On the **Select Backup** page, choose the **Restore Mode** you want to use. You can restore from a specific backup snapshot or restore to a specific point in time. - - -
- - To restore from a selected backup snapshot, take the following steps: - - 1. Click **Snapshot Restore**. - 2. Select the backup snapshot you want to restore from. - -
-
- - To restore to a specific point in time for a Premium or BYOC instance, take the following steps: - - 1. Click **Point-in-Time Restore**. - 2. Select the date and time you want to restore to. - -
- - -4. Click **Next** to proceed to the **Restore to a New Instance** page. - -5. Configure your new {{{ .premium }}} or {{{ .byoc }}} instance for restoration. Follow the steps in [Create a {{{ .premium }}} Instance](/tidb-cloud/premium/create-tidb-instance-premium.md)[Create a {{{ .byoc }}} Instance](/tidb-cloud/byoc/create-tidb-instance-byoc.md). - - - - For {{{ .byoc }}}, select an active resource pool in the same cloud provider and region as the backup. The restored instance inherits the high availability mode of the selected resource pool. You can restore the same backup to a Zonal or Regional resource pool. If no suitable resource pool is available, an `Organization Owner` can create one before restoring the instance. Other roles cannot create resource pools. For more information, see [Create a Resource Pool](/tidb-cloud/byoc/create-resource-pool-byoc.md). - - If the selected resource pool has a Pool vCPU Limit and its current provisioned vCPU is greater than or equal to the limit, TiDB Cloud displays a warning and you cannot restore the instance to that resource pool. To continue, go to the Resource Pool details page to increase or turn off the Pool vCPU Limit, or select another resource pool. - - > **Note:** - > - > Even if the current provisioned vCPU is below the Pool vCPU Limit, restoring an instance might cause the total provisioned vCPU to exceed the limit. This might constrain resource scaling and degrade the performance of all instances in the resource pool. Before restoring the instance, make sure that the resource pool has sufficient vCPU capacity. If necessary, increase or turn off the Pool vCPU Limit, or select another resource pool. - - - - > **Note:** - > - > The new instance uses the same cloud provider and region as the backup by default. - -6. Click **Restore** to start the restore process. - - When the restore process starts, the instance status first changes to **Creating**. After the creation is complete, it changes to **Restoring**. The instance remains unavailable until the restore finishes and the status changes to **Available**. - -### Restore from Recycle Bin - -To restore a deleted {{{ .premium }}} or {{{ .byoc }}} instance from the Recycle Bin, take the following steps: - -1. In the [TiDB Cloud console](https://tidbcloud.com), navigate to the [**My TiDB**](https://tidbcloud.com/tidbs) page of your organization, click **...** in the upper-right corner, and then click **Recycle Bin**. - - > **Tip:** - > - > If you are in multiple organizations, use the combo box in the upper-left corner to switch to your target organization first. - -2. On the **Recycle Bin** page, click the **Premium****BYOC** tab to go to the recycle bin of {{{ .premium }}}{{{ .byoc }}} instances. - -3. Locate the {{{ .premium }}}{{{ .byoc }}} instance you want to restore, and then click the **>** button to expand the available backups of the instance. - -4. In the row of your desired backup, click **...**, and then select **Restore**. - -5. On the **Restore** page, follow the same steps as [Restore to a new instance](#restore-to-a-new-instance) to restore the backup to a new instance. - - - -### Restore backups from a different plan type - -Currently, you can only restore backups from a {{{ .dedicated }}} cluster hosted on AWS to a new {{{ .premium }}} instance. - -To restore a backup generated by a {{{ .dedicated }}} cluster, follow these steps: - -1. Log in to the [TiDB Cloud console](https://tidbcloud.com), and then navigate to the [**My TiDB**](https://tidbcloud.com/tidbs) page. In the upper-right corner, click **...**, and then click **Restore from Another Plan**. - -2. On the **Select Backup** page, select the project that contains the target {{{ .dedicated }}} cluster. Select the {{{ .dedicated }}} cluster, select the backup snapshot that you want to restore, and then click **Next**. - - > **Note:** - > - > - Ensure that the {{{ .dedicated }}} cluster that contains the backup snapshot is in either the **Active** or **Deleted** status within the selected project. - > - The snapshot must be located in a region that {{{ .premium }}} supports. If the region is not supported, contact [TiDB Cloud Support](/tidb-cloud/tidb-cloud-support.md) to open a new region for {{{ .premium }}}, or select another backup snapshot. - -3. On the **Restore** page, follow the same steps as [Restore to a new instance](#restore-to-a-new-instance) to restore the backup to a new instance. - - - -### Restore backups from cloud storage - - - -{{{ .premium }}} supports restoring backups from cloud storage (such as Amazon S3 and Alibaba Cloud Object Storage Service (OSS)) to a new instance. This feature is compatible with backups generated from {{{ .dedicated }}} clusters or TiDB Self-Managed clusters. - - - - - -{{{ .premium }}} and {{{ .byoc }}} support restoring backups from cloud storage (such as Amazon S3) to a new instance. This feature is compatible with backups generated from {{{ .dedicated }}} clusters or TiDB Self-Managed clusters. - - - - - -> **Note:** -> -> - Currently, only backups located in **Amazon S3** and **Alibaba Cloud OSS** are supported for restore. -> - You can restore backups only to a new instance hosted by the same cloud provider as your storage bucket. -> - If the instance and the storage bucket are located in different regions, additional cross-region data transfer fees might apply. - - - - - -> **Note:** -> -> - Currently, only backups located in **Amazon S3** are supported for restore. -> - You can restore backups only to a new instance hosted by the same cloud provider as your storage bucket. -> - If the instance and the storage bucket are located in different regions, additional cross-region data transfer fees might apply. - - - -#### Steps - -Before you begin, ensure that you have an access key and secret key with sufficient permissions to access the backup files. - -To restore backups from cloud storage, do the following: - -1. Log in to the [TiDB Cloud console](https://tidbcloud.com), and then navigate to the [**My TiDB**](https://tidbcloud.com/tidbs) page. In the upper-right corner, click **...** , and then click **Restore from Cloud Storage**. - -2. On the **Select Backup Storage Location** page, provide the following information: - - - - - **Cloud Provider**: select the cloud provider where your backup files are stored. - - **Region**: if your cloud provider is Alibaba Cloud OSS, select a region. - - **Backup Files URI**: enter the URI of the top-level folder that contains your backup files. - - **Access Key ID**: enter your access key ID. - - **Access Key Secret**: enter your access key secret. - - - - - - - **Cloud Provider**: select the cloud provider where your backup files are stored. - - **Backup Files URI**: enter the URI of the top-level folder that contains your backup files. - - **Access Key ID**: enter your access key ID. - - **Access Key Secret**: enter your access key secret. - - - - > **Tip:** - > - > To create an access key for your storage bucket, see [Configure Amazon S3 access using an AWS access key](#configure-amazon-s3-access-using-an-aws-access-key) and [Configure Alibaba Cloud OSS access](#configure-alibaba-cloud-oss-access). - -3. Click **Verify Backup and Next**. - -4. If the verification is successful, the **Restore to a New Instance** page appears. Review the backup information displayed at the top of the page, and then follow the steps in [Create a {{{ .premium }}} Instance](/tidb-cloud/premium/create-tidb-instance-premium.md)[Create a {{{ .byoc }}} Instance](/tidb-cloud/byoc/create-tidb-instance-byoc.md) to restore the backup to a new instance. - - - - For {{{ .byoc }}}, select an active resource pool that matches the target cloud provider and region. The restored instance inherits the high availability mode of the selected resource pool. You can restore the same backup to a Zonal or Regional resource pool. If no suitable resource pool is available, an `Organization Owner` can create one before restoring the instance. Other roles cannot create resource pools. For more information, see [Create a Resource Pool](/tidb-cloud/byoc/create-resource-pool-byoc.md). - - If the selected resource pool has a Pool vCPU Limit and its current provisioned vCPU is greater than or equal to the limit, TiDB Cloud displays a warning and you cannot restore the instance to that resource pool. To continue, go to the Resource Pool details page to increase or turn off the Pool vCPU Limit, or select another resource pool. - - > **Note:** - > - > Even if the current provisioned vCPU is below the Pool vCPU Limit, restoring an instance might cause the total provisioned vCPU to exceed the limit. This might restrict resource scaling and affect the performance of all instances in the resource pool. Before restoring the instance, make sure that the resource pool has sufficient vCPU capacity. If necessary, increase or turn off the Pool vCPU Limit, or select another resource pool. - - - - If the backup information is incorrect, click **Previous** to return to the previous page, and then enter the correct information. - -5. Click **Restore** to restore the backup. - -## References - -This section describes how to configure access for Amazon S3 and Alibaba Cloud OSS. - -### Configure Amazon S3 access using an AWS access key - -It is recommended that you use an IAM user, rather than the AWS account root user, to create an access key. - -Take the following steps to configure an access key: - -1. Create an IAM user and access key. - - 1. Create an IAM user. For more information, see [Create an IAM user in your AWS account](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_create.html#id_users_create_console). - 2. Sign in to the [IAM console](https://console.aws.amazon.com/iam) using your AWS account ID or account alias, and your IAM user name and password. - 3. Create an access key. For more information, see [Manage access keys for IAM users](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#Using_CreateAccessKey). - -2. Grant permissions to the IAM user. - - Create a policy with only the permissions required for your task and attach it to the IAM user. To restore data to a {{{ .premium }}} or {{{ .byoc }}} instance, grant the `s3:GetObject`, `s3:GetBucketLocation`, and `s3:ListBucket` permissions. - - The following is an example policy that allows TiDB Cloud to restore data from a specific folder in your Amazon S3 bucket. - - ```json - { - "Version": "2012-10-17", - "Statement": [ - { - "Sid": "AllowGetBucketLocation", - "Effect": "Allow", - "Action": "s3:GetBucketLocation", - "Resource": "arn:aws:s3:::" - }, - { - "Sid": "AllowListPrefix", - "Effect": "Allow", - "Action": "s3:ListBucket", - "Resource": "arn:aws:s3:::", - "Condition": { - "StringLike": { - "s3:prefix": "/*" - } - } - }, - { - "Sid": "AllowReadObjectsInPrefix", - "Effect": "Allow", - "Action": "s3:GetObject", - "Resource": "arn:aws:s3::://*" - } - ] - } - ``` - - In the preceding policy, replace `` and `` with your actual bucket name and backup directory. This configuration follows the principle of least privilege by limiting access to only the necessary backup files. - -> **Note:** -> -> TiDB Cloud does not store your access keys. To maintain security, [delete the access key](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#Using_CreateAccessKey) after the import or export task is complete. - - - -### Configure Alibaba Cloud OSS access - -To grant TiDB Cloud access to your Alibaba Cloud OSS bucket, you need to create an AccessKey pair for the bucket. - -Take the following steps to configure an AccessKey pair: - -1. Create a RAM user and obtain the AccessKey pair. For more information, see [Create a RAM user](https://www.alibabacloud.com/help/en/ram/user-guide/create-a-ram-user). - - In the **Access Mode** section, select **Using permanent AccessKey to access**. - -2. Create a custom policy with the required permissions. For more information, see [Create custom policies](https://www.alibabacloud.com/help/en/ram/user-guide/create-a-custom-policy). - - - In the **Effect** section, select **Allow**. - - In the **Service** section, select **Object Storage Service**. - - In the **Action** section, select the required permissions. To restore a backup to a {{{ .premium }}} instance, grant the `oss:ListObjects` and `oss:GetObject` permissions. - - > **Tip:** - > - > To enhance security for restore operations, you can restrict access to the specific folder (`oss:Prefix`) where your backup files are stored rather than granting access to the entire bucket. - - The following JSON example shows a policy for a restore task. This policy restricts access to a specific bucket and backup folder. - - ```json - { - "Version": "1", - "Statement": [ - { - "Effect": "Allow", - "Action": "oss:ListObjects", - "Resource": "acs:oss:*:*:", - "Condition": { - "StringLike": { - "oss:Prefix": "/*" - } - } - }, - { - "Effect": "Allow", - "Action": "oss:GetObject", - "Resource": "acs:oss:*:*://*" - } - ] - } - ``` - - - In the **Resource** section, select the bucket and the specific objects in the bucket. - -3. Attach the custom policies to the RAM user. - - For more information, see [Grant permissions to a RAM user](https://www.alibabacloud.com/help/en/ram/user-guide/grant-permissions-to-the-ram-user). - - +--- +title: Back Up and Restore {{{ .premium }}} Data +summary: Learn how to back up and restore your {{{ .premium }}} instances. +aliases: ['/tidbcloud/restore-deleted-tidb-cluster'] +--- + +# Back Up and Restore {{{ .premium }}} Data + + + +This document describes how to back up and restore your data on {{{ .premium }}} instances. {{{ .premium }}} supports both automatic backups and manual backups, and lets you restore backup data to a new instance as needed. + + + + + +This document describes how to back up and restore your data on {{{ .premium }}} or {{{ .byoc }}} instances. {{{ .premium }}} and {{{ .byoc }}} support both automatic backups and manual backups, and let you restore backup data to a new instance as needed. + + + +Backup files can originate from the following sources: + +- Active {{{ .premium }}} or {{{ .byoc }}} instances +- The Recycle Bin for backups from deleted {{{ .premium }}} or {{{ .byoc }}} instances + +> **Tip:** +> +> - To learn how to back up and restore data on {{{ .dedicated }}} clusters, see [Back Up and Restore {{{ .dedicated }}} Data](/tidb-cloud/backup-and-restore.md). +> - To learn how to back up and restore data on {{{ .starter }}} or {{{ .essential }}} instances, see [Back Up and Restore {{{ .starter }}} or Essential Data](/tidb-cloud/backup-and-restore-serverless.md). + +## View the Backup page + +1. On the [**My TiDB**](https://tidbcloud.com/tidbs) page, click the name of your target {{{ .premium }}} or {{{ .byoc }}} instance to go to its overview page. + + > **Tip:** + > + > If you are in multiple organizations, use the combo box in the upper-left corner to switch to your target organization first. + +2. In the left navigation pane, click **Data** > **Backup**. + +## Automatic backups + + + +{{{ .premium }}} provides enhanced automatic backup capabilities for production environments. It combines high-frequency snapshots with log backups to ensure data reliability. + + + + + +{{{ .premium }}} and {{{ .byoc }}} provide enhanced automatic backup capabilities for production environments. They combine high-frequency snapshots with log backups to ensure data reliability. + + + +### Automatic backup modes + +You can choose an automatic backup mode in **Backup Settings**. The available backup types, retention periods, and pricing model depend on the selected mode. + + + +| Backup mode | Supported backup types | Retention and restore options | Pricing model | +| --- | --- | --- | --- | +| **Standard Bundle Mode** |
  • PITR
  • Hourly backup snapshots
  • Daily backup snapshots
|
  • PITR: 7 days
  • Hourly snapshots: 7 days
  • Daily snapshots: 33 days
  • Daily snapshots are created at 00:00 UTC.
| Based on incremental data volume. | +| **Custom Retention Mode** |
  • PITR
  • Daily backup snapshots
| You can set the retention period from 3 to 33 days. PITR and daily snapshots use the configured retention period. | Based on snapshot size multiplied by retention duration. Each backup is billed as a separate object. | + + + + + +| Backup mode | Supported backup types | Retention and restore options | +| --- | --- | --- | +| **Standard Bundle Mode** |
  • PITR
  • Hourly backup snapshots
  • Daily backup snapshots
|
  • PITR: 7 days
  • Hourly snapshots: 7 days
  • Daily snapshots: 33 days
  • Daily snapshots are created at 00:00 UTC.
| +| **Custom Retention Mode** |
  • PITR
  • Daily backup snapshots
| You can set the retention period from 3 to 33 days. PITR and daily snapshots use the configured retention period. | + + + +PITR lets you restore data to any point in time within the retention period. A snapshot lets you restore data from a specific hourly or daily snapshot that is still within the retention period. + +### Configure automatic backups + +1. On the [**My TiDB**](https://tidbcloud.com/tidbs) page, click the name of your target {{{ .premium }}} or {{{ .byoc }}} instance. + +2. In the left navigation pane, click **Data** > **Backup**. + +3. In the upper-right corner, click **...**, and then click **Backup Settings**. + +4. Select an automatic backup mode: + + - **Standard Bundle Mode** uses predefined settings for PITR, hourly snapshots, and daily snapshots. + - **Custom Retention Mode** lets you specify the automatic backup retention period and daily backup time. + +5. If you select **Custom Retention Mode**, configure the following settings. Otherwise, skip this step. + + - **Backup Retention**: select a retention period from 3 to 33 days. The default value is 7 days. + - **Daily Backup Time**: select the time of day for the daily snapshot. The time zone is displayed next to the setting. + +6. Review the **Overview** section, and then click **Save**. + + The overview shows the backup types enabled by the selected backup mode, the corresponding retention periods, and the available restore options. + + + +> **Note:** +> +> If you [switch between backup modes](#switch-between-automatic-backup-modes) or reduce the retention period, TiDB Cloud might permanently delete existing automatic backups that are older than the new retention period. This action cannot be undone. + + + + + +> **Note:** +> +> - Custom Retention Mode pricing is based on snapshot size and retention duration. PITR is temporarily free during the public preview period. See [TiDB Cloud pricing](https://www.pingcap.com/tidb-cloud-premium-pricing-details) for more information. +> - If you [switch between backup modes](#switch-between-automatic-backup-modes) or reduce the retention period, TiDB Cloud might permanently delete existing automatic backups that are older than the new retention period. This action cannot be undone. + + + +### Switch between automatic backup modes + +To switch between **Standard Bundle Mode** and **Custom Retention Mode**, take the following steps: + +1. Navigate to the [**Backup**](#view-the-backup-page) page of your instance. +2. In the upper-right corner, click **...**, and then click **Backup Settings**. +3. In the displayed dialog, select a new mode. + + - If you switch to **Custom Retention Mode**, you need to configure the backup retention period and daily backup time. + - If you switch to **Standard Bundle Mode**, the retention periods and daily backup time are reset to the standard bundle defaults. + +4. Review the retention settings in the **Overview** section, and then click **Save**. + + + +After you save the changes, future automatic backups are billed according to the pricing model of the selected mode. + + + +If the new retention period is shorter than the current retention period, the confirmation dialog lists the automatic backups that are older than the new retention period and will be permanently deleted. Confirm the operation only after verifying that you no longer need those backups. + +### Backup protection + +To help prevent data loss and preserve a recovery point, TiDB Cloud protects **the latest successful automatic backup** of an instance until its retention period expires. Therefore, you cannot manually delete this protected latest backup, even after the instance is deleted. If you attempt to delete it, the console displays a message explaining that the backup is protected and cannot be deleted before it expires. + +### Delete backup files + +To delete an existing backup file for your {{{ .premium }}} or {{{ .byoc }}} instance, perform the following steps: + +1. Navigate to the [**Backup**](#view-the-backup-page) page of your instance. + +2. Locate the corresponding backup file you want to delete, and click **...** > **Delete** in the **Action** column. + + > **Note:** + > + > TiDB Cloud protects the **latest successful automatic backup** of your instance to help prevent data loss. If you attempt to delete it, the console displays a message explaining that the backup is protected and cannot be deleted before it expires. + > If you have the `Organization Owner` or `Project Owner` role in TiDB Cloud, you can delete an automatic backup other than the latest successful one, or delete a manual backup. + +## Manual backups + + + +In addition to automatic backups, {{{ .premium }}} supports manual backups. A manual backup provides a controlled, guaranteed restore point. It is highly recommended that you create a manual backup before you perform high-risk operations such as system upgrades, critical data deletion, or irreversible schema or configuration changes. + + + + + +In addition to automatic backups, {{{ .premium }}} and {{{ .byoc }}} support manual backups. A manual backup provides a controlled, guaranteed restore point. It is highly recommended that you create a manual backup before you perform high-risk operations such as system upgrades, critical data deletion, or irreversible schema or configuration changes. + + + +### Key characteristics + +- **Retention and deletion**: unlike automatic backups, manual backups are not automatically deleted based on retention policies. They are retained until you explicitly delete them. If you delete the instance, its manual backups move to the recycle bin and remain there until you manually delete them. + +- **Storage location**: manual backups are stored in cloud storage managed by TiDB. + +- **Cost**: manual backups incur additional charges because they are retained until you delete them. + +- **Limitations**: manual backups do not support point-in-time recovery (PITR) or partial backups (for example, table-level or database-level backups). You cannot restore a manual backup to an existing instance. Each restore operation creates a new instance. + +- **Permissions**: both `Organization Owner` and `Instance Manager` can create manual backups. Only `Organization Owner` can restore system-managed manual backups. + +### Create a manual backup + +1. Navigate to the [**Backup**](#view-the-backup-page) page of your instance. + +2. In the upper-right corner, click **...**, and then click **Manual Backup**. + +3. Confirm the operation. The backup is stored in TiDB Cloud and will appear in the **Backup List**. + +You can restore a manual backup directly in the TiDB Cloud console without providing external storage credentials. + +## Restore + +TiDB Cloud provides restore functionality to help recover data in case of accidental loss or corruption. You can restore from backups of active instances or from deleted instances in the Recycle Bin. + +### Restore mode + +TiDB Cloud supports snapshot restore and point-in-time restore for your instance. + +- **Snapshot Restore**: restores your instance from a specific backup snapshot. You can use this method to restore both automatic and manual backups. In the **Backup List**, manual backups are labeled with the **Manual** type and a **Permanent** expiration status. + +- **Point-in-Time Restore**: restores your instance to a specific point in time. + + - Premium or BYOC instances: can be restored to any time within the last 7 days, but not earlier than the instance creation time or later than one minute before the current time. Note that PITR is not supported for manual backups. + +### Restore destination + +TiDB Cloud supports restoring data to a new instance. + +### Restore to a new {{{ .premium }}} instance {#restore-to-a-new-instance} + +To restore your data to a new {{{ .premium }}} or {{{ .byoc }}} instance, take the following steps: + +1. Navigate to the [**Backup**](#view-the-backup-page) page of your instance. + +2. Click **Restore**. + +3. On the **Select Backup** page, choose the **Restore Mode** you want to use. You can restore from a specific backup snapshot or restore to a specific point in time. + + +
+ + To restore from a selected backup snapshot, take the following steps: + + 1. Click **Snapshot Restore**. + 2. Select the backup snapshot you want to restore from. + +
+
+ + To restore to a specific point in time for a Premium or BYOC instance, take the following steps: + + 1. Click **Point-in-Time Restore**. + 2. Select the date and time you want to restore to. + +
+ + +4. Click **Next** to proceed to the **Restore to a New Instance** page. + +5. Configure your new {{{ .premium }}} or {{{ .byoc }}} instance for restoration. Follow the steps in [Create a {{{ .premium }}} Instance](/tidb-cloud/premium/create-tidb-instance-premium.md)[Create a {{{ .byoc }}} Instance](/tidb-cloud/byoc/create-tidb-instance-byoc.md). + + + + For {{{ .byoc }}}, select an active resource pool in the same cloud provider and region as the backup. The restored instance inherits the high availability mode of the selected resource pool. You can restore the same backup to a Zonal or Regional resource pool. If no suitable resource pool is available, an `Organization Owner` can create one before restoring the instance. Other roles cannot create resource pools. For more information, see [Create a Resource Pool](/tidb-cloud/byoc/create-resource-pool-byoc.md). + + If the selected resource pool has a Pool vCPU Limit and its current provisioned vCPU is greater than or equal to the limit, TiDB Cloud displays a warning and you cannot restore the instance to that resource pool. To continue, go to the Resource Pool details page to increase or turn off the Pool vCPU Limit, or select another resource pool. + + > **Note:** + > + > Even if the current provisioned vCPU is below the Pool vCPU Limit, restoring an instance might cause the total provisioned vCPU to exceed the limit. This might constrain resource scaling and degrade the performance of all instances in the resource pool. Before restoring the instance, make sure that the resource pool has sufficient vCPU capacity. If necessary, increase or turn off the Pool vCPU Limit, or select another resource pool. + + + + > **Note:** + > + > The new instance uses the same cloud provider and region as the backup by default. + +6. Click **Restore** to start the restore process. + + When the restore process starts, the instance status first changes to **Creating**. After the creation is complete, it changes to **Restoring**. The instance remains unavailable until the restore finishes and the status changes to **Available**. + +### Restore from Recycle Bin + +To restore a deleted {{{ .premium }}} or {{{ .byoc }}} instance from the Recycle Bin, take the following steps: + +1. In the [TiDB Cloud console](https://tidbcloud.com), navigate to the [**My TiDB**](https://tidbcloud.com/tidbs) page of your organization, click **...** in the upper-right corner, and then click **Recycle Bin**. + + > **Tip:** + > + > If you are in multiple organizations, use the combo box in the upper-left corner to switch to your target organization first. + +2. On the **Recycle Bin** page, click the **Premium****BYOC** tab to go to the recycle bin of {{{ .premium }}}{{{ .byoc }}} instances. + +3. Locate the {{{ .premium }}}{{{ .byoc }}} instance you want to restore, and then click the **>** button to expand the available backups of the instance. + +4. In the row of your desired backup, click **...**, and then select **Restore**. + +5. On the **Restore** page, follow the same steps as [Restore to a new instance](#restore-to-a-new-instance) to restore the backup to a new instance. + + + +### Restore backups from a different plan type + +Currently, you can only restore backups from a {{{ .dedicated }}} cluster hosted on AWS to a new {{{ .premium }}} instance. + +To restore a backup generated by a {{{ .dedicated }}} cluster, follow these steps: + +1. Log in to the [TiDB Cloud console](https://tidbcloud.com), and then navigate to the [**My TiDB**](https://tidbcloud.com/tidbs) page. In the upper-right corner, click **...**, and then click **Restore from Another Plan**. + +2. On the **Select Backup** page, select the project that contains the target {{{ .dedicated }}} cluster. Select the {{{ .dedicated }}} cluster, select the backup snapshot that you want to restore, and then click **Next**. + + > **Note:** + > + > - Ensure that the {{{ .dedicated }}} cluster that contains the backup snapshot is in either the **Active** or **Deleted** status within the selected project. + > - The snapshot must be located in a region that {{{ .premium }}} supports. If the region is not supported, contact [TiDB Cloud Support](/tidb-cloud/tidb-cloud-support.md) to open a new region for {{{ .premium }}}, or select another backup snapshot. + +3. On the **Restore** page, follow the same steps as [Restore to a new instance](#restore-to-a-new-instance) to restore the backup to a new instance. + + + +### Restore backups from cloud storage + + + +{{{ .premium }}} supports restoring backups from cloud storage (such as Amazon S3 and Alibaba Cloud Object Storage Service (OSS)) to a new instance. This feature is compatible with backups generated from {{{ .dedicated }}} clusters or TiDB Self-Managed clusters. + + + + + +{{{ .premium }}} and {{{ .byoc }}} support restoring backups from cloud storage (such as Amazon S3) to a new instance. This feature is compatible with backups generated from {{{ .dedicated }}} clusters or TiDB Self-Managed clusters. + + + + + +> **Note:** +> +> - Currently, only backups located in **Amazon S3** and **Alibaba Cloud OSS** are supported for restore. +> - You can restore backups only to a new instance hosted by the same cloud provider as your storage bucket. +> - If the instance and the storage bucket are located in different regions, additional cross-region data transfer fees might apply. + + + + + +> **Note:** +> +> - Currently, only backups located in **Amazon S3** are supported for restore. +> - You can restore backups only to a new instance hosted by the same cloud provider as your storage bucket. +> - If the instance and the storage bucket are located in different regions, additional cross-region data transfer fees might apply. + + + +#### Steps + +Before you begin, ensure that you have an access key and secret key with sufficient permissions to access the backup files. + +To restore backups from cloud storage, do the following: + +1. Log in to the [TiDB Cloud console](https://tidbcloud.com), and then navigate to the [**My TiDB**](https://tidbcloud.com/tidbs) page. In the upper-right corner, click **...** , and then click **Restore from Cloud Storage**. + +2. On the **Select Backup Storage Location** page, provide the following information: + + + + - **Cloud Provider**: select the cloud provider where your backup files are stored. + - **Region**: if your cloud provider is Alibaba Cloud OSS, select a region. + - **Backup Files URI**: enter the URI of the top-level folder that contains your backup files. + - **Access Key ID**: enter your access key ID. + - **Access Key Secret**: enter your access key secret. + + + + + + - **Cloud Provider**: select the cloud provider where your backup files are stored. + - **Backup Files URI**: enter the URI of the top-level folder that contains your backup files. + - **Access Key ID**: enter your access key ID. + - **Access Key Secret**: enter your access key secret. + + + + > **Tip:** + > + > To create an access key for your storage bucket, see [Configure Amazon S3 access using an AWS access key](#configure-amazon-s3-access-using-an-aws-access-key) and [Configure Alibaba Cloud OSS access](#configure-alibaba-cloud-oss-access). + +3. Click **Verify Backup and Next**. + +4. If the verification is successful, the **Restore to a New Instance** page appears. Review the backup information displayed at the top of the page, and then follow the steps in [Create a {{{ .premium }}} Instance](/tidb-cloud/premium/create-tidb-instance-premium.md)[Create a {{{ .byoc }}} Instance](/tidb-cloud/byoc/create-tidb-instance-byoc.md) to restore the backup to a new instance. + + + + For {{{ .byoc }}}, select an active resource pool that matches the target cloud provider and region. The restored instance inherits the high availability mode of the selected resource pool. You can restore the same backup to a Zonal or Regional resource pool. If no suitable resource pool is available, an `Organization Owner` can create one before restoring the instance. Other roles cannot create resource pools. For more information, see [Create a Resource Pool](/tidb-cloud/byoc/create-resource-pool-byoc.md). + + If the selected resource pool has a Pool vCPU Limit and its current provisioned vCPU is greater than or equal to the limit, TiDB Cloud displays a warning and you cannot restore the instance to that resource pool. To continue, go to the Resource Pool details page to increase or turn off the Pool vCPU Limit, or select another resource pool. + + > **Note:** + > + > Even if the current provisioned vCPU is below the Pool vCPU Limit, restoring an instance might cause the total provisioned vCPU to exceed the limit. This might restrict resource scaling and affect the performance of all instances in the resource pool. Before restoring the instance, make sure that the resource pool has sufficient vCPU capacity. If necessary, increase or turn off the Pool vCPU Limit, or select another resource pool. + + + + If the backup information is incorrect, click **Previous** to return to the previous page, and then enter the correct information. + +5. Click **Restore** to restore the backup. + +## References + +This section describes how to configure access for Amazon S3 and Alibaba Cloud OSS. + +### Configure Amazon S3 access using an AWS access key + +It is recommended that you use an IAM user, rather than the AWS account root user, to create an access key. + +Take the following steps to configure an access key: + +1. Create an IAM user and access key. + + 1. Create an IAM user. For more information, see [Create an IAM user in your AWS account](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_create.html#id_users_create_console). + 2. Sign in to the [IAM console](https://console.aws.amazon.com/iam) using your AWS account ID or account alias, and your IAM user name and password. + 3. Create an access key. For more information, see [Manage access keys for IAM users](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#Using_CreateAccessKey). + +2. Grant permissions to the IAM user. + + Create a policy with only the permissions required for your task and attach it to the IAM user. To restore data to a {{{ .premium }}} or {{{ .byoc }}} instance, grant the `s3:GetObject`, `s3:GetBucketLocation`, and `s3:ListBucket` permissions. + + The following is an example policy that allows TiDB Cloud to restore data from a specific folder in your Amazon S3 bucket. + + ```json + { + "Version": "2012-10-17", + "Statement": [ + { + "Sid": "AllowGetBucketLocation", + "Effect": "Allow", + "Action": "s3:GetBucketLocation", + "Resource": "arn:aws:s3:::" + }, + { + "Sid": "AllowListPrefix", + "Effect": "Allow", + "Action": "s3:ListBucket", + "Resource": "arn:aws:s3:::", + "Condition": { + "StringLike": { + "s3:prefix": "/*" + } + } + }, + { + "Sid": "AllowReadObjectsInPrefix", + "Effect": "Allow", + "Action": "s3:GetObject", + "Resource": "arn:aws:s3::://*" + } + ] + } + ``` + + In the preceding policy, replace `` and `` with your actual bucket name and backup directory. This configuration follows the principle of least privilege by limiting access to only the necessary backup files. + +> **Note:** +> +> TiDB Cloud does not store your access keys. To maintain security, [delete the access key](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#Using_CreateAccessKey) after the import or export task is complete. + + + +### Configure Alibaba Cloud OSS access + +To grant TiDB Cloud access to your Alibaba Cloud OSS bucket, you need to create an AccessKey pair for the bucket. + +Take the following steps to configure an AccessKey pair: + +1. Create a RAM user and obtain the AccessKey pair. For more information, see [Create a RAM user](https://www.alibabacloud.com/help/en/ram/user-guide/create-a-ram-user). + + In the **Access Mode** section, select **Using permanent AccessKey to access**. + +2. Create a custom policy with the required permissions. For more information, see [Create custom policies](https://www.alibabacloud.com/help/en/ram/user-guide/create-a-custom-policy). + + - In the **Effect** section, select **Allow**. + - In the **Service** section, select **Object Storage Service**. + - In the **Action** section, select the required permissions. To restore a backup to a {{{ .premium }}} instance, grant the `oss:ListObjects` and `oss:GetObject` permissions. + + > **Tip:** + > + > To enhance security for restore operations, you can restrict access to the specific folder (`oss:Prefix`) where your backup files are stored rather than granting access to the entire bucket. + + The following JSON example shows a policy for a restore task. This policy restricts access to a specific bucket and backup folder. + + ```json + { + "Version": "1", + "Statement": [ + { + "Effect": "Allow", + "Action": "oss:ListObjects", + "Resource": "acs:oss:*:*:", + "Condition": { + "StringLike": { + "oss:Prefix": "/*" + } + } + }, + { + "Effect": "Allow", + "Action": "oss:GetObject", + "Resource": "acs:oss:*:*://*" + } + ] + } + ``` + + - In the **Resource** section, select the bucket and the specific objects in the bucket. + +3. Attach the custom policies to the RAM user. + + For more information, see [Grant permissions to a RAM user](https://www.alibabacloud.com/help/en/ram/user-guide/grant-permissions-to-the-ram-user). + + From 252b433b7b76ecdbebcac0e5c4b7a9f333892145 Mon Sep 17 00:00:00 2001 From: Grace Cai Date: Wed, 26 Aug 2026 09:34:48 +0800 Subject: [PATCH 18/20] Apply suggestions from code review --- tidb-cloud/architecture-concepts.md | 573 +++++++++--------- tidb-cloud/byoc/create-resource-pool-byoc.md | 2 +- .../premium/backup-and-restore-premium.md | 4 +- 3 files changed, 290 insertions(+), 289 deletions(-) diff --git a/tidb-cloud/architecture-concepts.md b/tidb-cloud/architecture-concepts.md index d91d83d7799bd..597058d76b779 100644 --- a/tidb-cloud/architecture-concepts.md +++ b/tidb-cloud/architecture-concepts.md @@ -1,286 +1,287 @@ ---- -title: Architecture -summary: Learn about architecture concepts for TiDB Cloud. ---- - -# Architecture - - - -TiDB Cloud is a fully-managed Database-as-a-Service (DBaaS) that brings the flexibility and power of [TiDB](https://docs.pingcap.com/tidb/stable/overview), an open-source HTAP (Hybrid Transactional and Analytical Processing) database, to Amazon Web Services (AWS), Google Cloud, Microsoft Azure, and Alibaba Cloud. - - - - - -TiDB Cloud is a fully-managed Database-as-a-Service (DBaaS) that brings the flexibility and power of [TiDB](https://docs.pingcap.com/tidb/stable/overview), an open-source HTAP (Hybrid Transactional and Analytical Processing) database, to Amazon Web Services (AWS), Google Cloud, and Microsoft Azure. - - - -TiDB is MySQL-compatible, making it easy to migrate and work with existing applications, while offering seamless scalability to handle everything from small workloads to massive, high-performance systems. It supports both transactional (OLTP) and analytical (OLAP) workloads in one system, simplifying operations and enabling real-time insights. - -TiDB Cloud makes it easy to scale your database, handle complex management tasks, and stay focused on developing reliable, high-performing applications. - - - -- For AWS, TiDB Cloud provides **{{{ .starter }}}** for auto-scaling, cost-efficient workloads, **{{{ .essential }}}** for production-ready workloads with provisioned capacity, **{{{ .premium }}}** for mission-critical workloads that require high performance and enhanced security, and **{{{ .dedicated }}}** for enterprise-grade applications with dedicated resources and advanced capabilities. -- For Google Cloud and Azure, TiDB Cloud provides **{{{ .dedicated }}}** for enterprise-grade applications with dedicated resources and advanced capabilities. -- For Alibaba Cloud, TiDB Cloud provides **{{{ .starter }}}** for auto-scaling, cost-efficient workloads, **{{{ .essential }}}** for production-ready workloads with provisioned capacity, and **{{{ .premium }}}** for mission-critical workloads that require high performance and enhanced security. - - - - - -- For AWS, TiDB Cloud provides **{{{ .starter }}}** for auto-scaling, cost-efficient workloads, **{{{ .essential }}}** for production-ready workloads with provisioned capacity, **{{{ .premium }}}** for mission-critical workloads that require high performance and enhanced security, and **{{{ .dedicated }}}** for enterprise-grade applications with dedicated resources and advanced capabilities. -- For Google Cloud and Azure, TiDB Cloud provides **{{{ .dedicated }}}** for enterprise-grade applications with dedicated resources and advanced capabilities. - - - -## {{{ .starter }}} - -{{{ .starter }}} is a fully managed, multi-tenant TiDB offering. It delivers an instant, autoscaling MySQL-compatible database. - -The Starter plan is ideal for those who are getting started with TiDB Cloud. It provides developers and small teams with the following features: - -- **No cost**: This plan is free when usage is within the [free quota](https://www.pingcap.com/tidb-cloud-starter-pricing-details/). No credit card is required to get started. - -- **Storage**: Provides an initial 5 GiB of row-based storage and 5 GiB of columnar storage. -- **Request Units**: Includes 50 million [Request Units (RUs)](/tidb-cloud/tidb-cloud-glossary.md#request-unit-ru) for database operations. - -## {{{ .essential }}} - -For applications experiencing growing workloads and needing scalability in real time, the Essential plan provides the flexibility and performance to keep pace with your business growth with the following features: - - - -- **Enhanced capabilities**: includes all capabilities of the Starter plan, along with the capacity to handle larger and more complex workloads, as well as advanced security features. -- **Automatic scaling**: automatically adjusts storage and computing resources to efficiently meet changing workload demands. -- **Predictable pricing**: billed based on storage and Request Capacity Units (RCUs) of the compute resources, offering transparent, usage-based pricing that scales with your needs, so you only pay for what you use without surprises. - -{{{ .essential }}} offers zonal high availability, which places all components within the same availability zone to reduce network latency. For more information, see [High Availability in TiDB Cloud](/tidb-cloud/serverless-high-availability.md). - - - - - -- **Enhanced capabilities**: includes all capabilities of the Starter plan, along with the capacity to handle larger and more complex workloads, as well as advanced security features. -- **Automatic scaling**: automatically adjusts storage and computing resources to efficiently meet changing workload demands. -- **High availability**: built-in fault tolerance and redundancy ensure your applications remain available and resilient, even during infrastructure failures. -- **Predictable pricing**: billed based on storage and Request Capacity Units (RCUs) of the compute resources, offering transparent, usage-based pricing that scales with your needs, so you only pay for what you use without surprises. - -{{{ .essential }}} offers two types of high availability to address varying operational requirements. - -- Zonal High Availability: places all components within the same availability zone, which results in lower network latency. -- Regional High Availability: distributes nodes across multiple availability zones, providing maximum infrastructure isolation and redundancy. - -For more information, see [High Availability in TiDB Cloud](/tidb-cloud/serverless-high-availability.md). - - - -## {{{ .premium }}} - -For mission-critical applications that require high performance and enhanced security in a managed environment, the Premium plan provides robust infrastructure and advanced controls with the following features: - -- **Unlimited growth and auto-scaling**: provides seamless scaling to handle evolving workloads, ensuring continuous reliability for business-critical operations. -- **Performance optimization**: tuned for high-throughput and low-latency workloads, offering larger resource ceilings and more granular scaling controls. -- **Pay-as-you-go pricing**: billed based on actual [Request Capacity Unit (RCU)](/tidb-cloud/tidb-cloud-glossary.md#request-capacity-unit-rcu) consumption and storage usage. This flexible model eliminates the need for manual backend over-provisioning. -- **Advanced security**: offers deeper security configurations and compliance capabilities required by large-scale enterprises and regulated industries. - -To maximize uptime and resilience for mission-critical workloads, {{{ .premium }}} provides [Regional High Availability](/tidb-cloud/serverless-high-availability.md#regional-high-availability-architecture), which distributes nodes across multiple availability zones for greater redundancy than zonal deployments. - - - -## TiDB Cloud BYOC - -TiDB Cloud BYOC (Bring Your Own Cloud) is designed for organizations that need stronger control over data location, cloud resources, network boundaries, and compliance posture while still using TiDB Cloud as a managed service. With BYOC, the TiDB Cloud control plane is managed by PingCAP, while the TiDB data plane runs in your own cloud account. - -BYOC provides the following features: - -- **Customer-owned data plane**: keeps TiDB service resources, data storage, and network boundaries in your cloud account. -- **Managed operations**: uses TiDB Cloud for deployment, scaling, monitoring, upgrades, backup, and lifecycle management. -- **Flexible high availability**: supports both Single-AZ and Multi-AZ deployments so you can choose between lower-latency zonal deployment and higher-resilience regional deployment. -- **Cloud-account-level controls**: lets you apply your own cloud policies for networking, security, auditability, and compliance. -- **Private connectivity**: supports private network access patterns such as VPC peering, depending on your BYOC configuration. - -To meet different workload requirements, TiDB Cloud BYOC supports both Single-AZ and Multi-AZ deployments, enabling you to choose between lower-latency zonal deployment and higher-resilience deployment across multiple availability zones. - -You can configure high availability mode for each resource pool as **Zonal** or **Regional** when you [create the pool](/tidb-cloud/byoc/create-resource-pool-byoc.md). A zonal resource pool is deployed in a single availability zone, while a regional resource pool is deployed across multiple availability zones. TiDB Cloud determines the availability zone placement based on the BYOC region configuration and available cloud resources. TiDB Cloud BYOC instances created or restored in a resource pool inherit the high availability mode of the pool. After a resource pool is created, you cannot change its high availability mode or availability zone placement. - -![TiDB Cloud BYOC Architecture](/media/tidb-cloud/byoc-architecture.png) - -A TiDB Cloud BYOC deployment includes the following major components: - -- **TiDB Cloud control plane**: provides the TiDB Cloud console, organization and project management, billing, lifecycle orchestration, monitoring views, alerting, and maintenance workflows. -- **BYOC data plane**: runs the TiDB service and related infrastructure in your cloud account. TiDB Cloud operates this environment based on the permissions granted during BYOC onboarding. -- **Resource pool**: defines the underlying physical resource, network, and capacity boundary for one or more {{{ .byoc }}} instances. Each resource pool has its own capacity configuration, resource pool CIDR, high availability mode, and AWS resource tags. -- **TiDB service VPC**: hosts TiDB service components that serve application traffic. -- **Observability service VPC**: hosts observability components used to collect metrics, logs, and operational data for the BYOC deployment. -- **Application VPC**: hosts your applications. You manage this VPC and configure network connectivity to access the BYOC TiDB service. - -Each BYOC region is deployed and operated independently. When a BYOC region is added, TiDB Cloud provisions the required regional resources in your cloud account. Because each BYOC region has its own data-plane setup, regions do not share a single TiDB Service VPC or Observability Service VPC. - -Your applications connect to a {{{ .byoc }}} instance from your application environment. Depending on your BYOC configuration, connections use either private or controlled public access. For private access, BYOC supports VPC peering and other private connectivity options. - - - -## TiDB Cloud Dedicated - -TiDB Cloud Dedicated is designed for mission-critical businesses, offering high availability across multiple availability zones, horizontal scaling, and full HTAP capabilities. - -Built on isolated cloud resources such as VPCs, VMs, managed Kubernetes services, and cloud storage, it leverages the infrastructure of major cloud providers. TiDB Cloud Dedicated clusters support the complete TiDB feature set, enabling rapid scaling, reliable backups, deployment within specific VPCs, and geographic-level disaster recovery. - -![TiDB Cloud Dedicated Architecture](/media/tidb-cloud/tidb-cloud-dedicated-architecture.png) - -## {{{ .lake }}} {#lake} - -TiDB Cloud Lake is a cloud-native data warehouse service for analytics workloads. It separates compute and storage, allowing you to provision warehouses independently, scale with workload changes, and store data cost-effectively in object storage. - -TiDB Cloud Lake supports ANSI SQL, semi-structured data processing, vector search, and AI-oriented workflows in one platform. It is designed for teams that want a managed analytics experience without operating the underlying infrastructure themselves. - -For more details, see [TiDB Cloud Lake Overview](https://docs.pingcap.com/tidbcloudlake/lake-overview/). - -## TiDB Cloud console - -The [TiDB Cloud console](https://tidbcloud.com/) is the web-based management interface for TiDB Cloud resources. It provides tools to manage TiDB Cloud resources, import or migrate data, monitor performance metrics, configure backups, set up security controls, and integrate with other cloud services, all from a single, user-friendly platform. - -## TiDB Cloud CLI (PREVIEW) - -The TiDB Cloud CLI, `ticloud`, allows you to manage {{{ .starter }}} and Essential instances directly from your terminal with simple commands. You can perform tasks such as: - -- Creating, deleting, and listing {{{ .starter }}} and Essential instances. -- Importing data into {{{ .starter }}} and Essential instances. -- Exporting data from {{{ .starter }}} and Essential instances. - -For more information, see [TiDB Cloud CLI Reference](/tidb-cloud/cli-reference.md). - -## TiDB Cloud API (PREVIEW) - -The TiDB Cloud API is a REST-based interface that provides programmatic access to manage resources across {{{ .starter }}}, {{{ .essential }}}, {{{ .premium }}}, and TiDB Cloud Dedicated. It enables automated and efficient handling of tasks such as managing projects, clusters, backups, restores, data imports, billing, and other resources in [TiDB Cloud Data Service](/tidb-cloud/data-service-overview.md). - -For more information, see [TiDB Cloud API Overview](https://docs.pingcap.com/api/tidb-cloud-api-overview). - -## Nodes - -Nodes are the core components of the TiDB architecture. TiDB nodes, TiKV nodes, and TiFlash nodes work together to process SQL queries, store data, and accelerate analytical workloads. - -- In a TiDB Cloud Dedicated cluster, you can fully manage the number and size of your dedicated TiDB, TiKV, and TiFlash nodes according to your performance requirements. For more information, see [Scalability](/tidb-cloud/scalability-concepts.md). -- In a {{{ .starter }}}, {{{ .essential }}}, or {{{ .premium }}} instance, the number and size of TiDB, TiKV, and TiFlash nodes are automatically managed. This ensures seamless scaling, eliminating the need for users to handle node configuration or management tasks. - -### TiDB node - -A [TiDB node](/tidb-computing.md) is a stateless SQL layer that connects to applications using a MySQL-compatible endpoint. It handles tasks like parsing, optimizing, and creating distributed execution plans for SQL queries. - -You can deploy multiple TiDB nodes to scale horizontally and manage higher workloads. These nodes work with load balancers, such as TiProxy or HAProxy, to provide a seamless interface. TiDB nodes do not store data themselves---they forward data requests to TiKV nodes for row-based storage or TiFlash nodes for columnar storage. - -### TiKV node - -A [TiKV node](/tikv-overview.md) is the backbone of data storage in the TiDB architecture, serving as a distributed transactional key-value storage engine that delivers reliability, scalability, and high availability. - -**Key features:** - -- **Region-based data storage** - - - Data is divided into [Regions](https://docs.pingcap.com/tidb/dev/glossary#regionpeerraft-group), each covering a specific Key Range (left-closed, right-open interval: `StartKey` to `EndKey`). - - Multiple Regions coexist within each TiKV node to ensure efficient data distribution. - -- **Transactional support** - - - TiKV nodes provide native distributed transaction support at the key-value level, ensuring Snapshot Isolation as the default isolation level. - - The TiDB node translates SQL execution plans into calls to the TiKV node API, enabling seamless SQL-level transaction support. - -- **High availability** - - - All data in TiKV nodes is replicated (default: three replicas) for durability. - - TiKV ensures native high availability and supports automatic failover, safeguarding against node failures. - -- **Scalability and reliability** - - - TiKV nodes are designed to handle expanding datasets while maintaining distributed consistency and fault tolerance. - -### TiFlash node - -A [TiFlash node](/tiflash/tiflash-overview.md) is a specialized type of storage node within the TiDB architecture. Unlike ordinary TiKV nodes, TiFlash is designed for analytical acceleration with a columnar storage model. - -**Key features:** - -- **Columnar storage** - - TiFlash nodes store data in a columnar format, making them optimized for analytical queries and significantly improving performance for read-intensive workloads. - -- **Vector search index support** - - The vector search index feature uses TiFlash replicas for tables, enabling advanced search capabilities and improving efficiency in complex analytical scenarios. - - - -## Request units and capacity in {{{ .premium }}} {#request-units-and-capacity-in-premium} - -### Request Capacity Unit (RCU) - -A [Request Capacity Unit (RCU)](/tidb-cloud/tidb-cloud-glossary.md#request-capacity-unit-rcu) is a unit of measure used to represent the provisioned compute capacity for your {{{ .premium }}} instance. One RCU provides a fixed amount of compute resources that can process a certain number of RUs per second. The number of RCUs you provision determines the baseline performance and throughput capacity of your {{{ .premium }}} instance. - -One RCU represents a sustained capacity of RUs per second. For example, a baseline of *X* RCUs guarantees *X* RUs per second on average, measured over a one-minute window (or the minimum calculation window configured for your instance). - -### RCU auto-scaling - -When configuring your {{{ .premium }}} instance, you specify the maximum number of RCUs (`RCU_max`) required for your workload. TiDB Cloud automatically scales capacity within the range of `0.25 * RCU_max` to `RCU_max`. - -For example, if you set the maximum capacity to 20,000 RCUs, TiDB Cloud dynamically scales the capacity between 5,000 and 20,000 RCUs based on real-time demand. This scaling is automatic and instantaneous, enabling you to consume up to the maximum number of RCUs at any time without manual intervention or delay. - -### RCU billing - -{{{ .premium }}} uses a usage-based billing model that charges you based on the actual Request Capacity Unit (RCU) consumption and storage usage. - -#### Per-minute calculation - -TiDB Cloud calculates your usage every minute. It measures the total number of Request Units (RUs) consumed within a 60-second window, calculates the average RUs per second, and uses this average value as the RCU consumption for that minute. This calculation ensures that your billing accurately reflects real-time traffic fluctuations. - -#### Minimum usage requirement - -To maintain baseline capacity and ensure that resources are always available for your instance, TiDB Cloud automatically sets a minimum billing RCU based on your maximum RCU setting. This value defines the baseline reserved capacity for your instance. - -If your actual consumption in a given minute is below this threshold, billing defaults to the minimum billing RCU. This mechanism ensures that your instance can immediately handle sudden traffic spikes up to your specified maximum, without performance degradation or delays. - -### Request Unit (RU) - -A [Request Unit (RU)](/tidb-cloud/tidb-cloud-glossary.md#request-unit-ru) is a unit of measure used to represent the resources consumed by a single request to the database. The number of RUs consumed by a request depends on factors such as the operation type and the amount of data retrieved or modified. - -{{{ .premium }}} normalizes the cost of all database operations using Request Units and measures this cost based on throughput (Request Units per second, RU/s). This unified metric makes your throughput costs predictable, helping you manage your application costs more effectively. - -#### Baseline performance examples - -The following table lists baseline performance examples for common operations to help you estimate your workload. - -| Operation type | Description | Estimated cost | -|----------------|------------------------------------------|----------------| -| Point read | Reading a 1 KiB item by its unique ID | 1.5 RU | -| OLTP write | Standard Sysbench model (1 KiB item size) | 2.5 RU | - -> **Note:** -> -> A point read is the most efficient way to retrieve data by its unique ID. For write operations, the RU cost accounts for the I/O and indexing effort required to persist the data. RU consumption scales proportionally with the data size and operation complexity. - -### Request Unit considerations - -TiDB Cloud calculates the total RU charge for any operation based on the database effort required to execute it. The calculation considers the following dimensions: - -- **Data access and size** - - - **Read and write volume**: RUs scale directly with the size of the data payload. Processing a 100 KiB record consumes more RUs than a 1 KiB record. - - **Read and write rows**: the number of rows involved in an operation is a primary cost driver. Even with small payloads, querying or updating multiple rows increases the total RU consumption because each row requires processing, locking, and validation. - - **Indexing impact**: - - - **Writes**: each affected index on a table must be updated during a write operation. Tables with more indexes incur higher RU costs for `INSERT`, `UPDATE`, and `DELETE` operations. - - **Reads**: well-designed indexes significantly reduce query RUs by enabling the engine to locate rows efficiently and avoid full-table scans. - -- **Query complexity** - - - **Scanning efficiency**: RU consumption is heavily influenced by the number of rows that the engine must scan. - - - **Read metrics (estimated rows)**: a point read that uses a primary key or unique index is the most efficient operation. A query that scans millions of rows consumes significantly more RUs than a query that uses an optimized index. - - - **Write metrics (affected rows)**: the RU cost for data modification is tied to the number of affected rows. Modifying 10,000 rows in a single statement results in a much higher charge than modifying a single row. - - - **Computational logic**: complex SQL operations, including multiple table joins, deep subqueries, and aggregations, require more CPU cycles to compute execution paths and process data. - - +--- +title: Architecture +summary: Learn about architecture concepts for TiDB Cloud. +--- + +# Architecture + + + +TiDB Cloud is a fully-managed Database-as-a-Service (DBaaS) that brings the flexibility and power of [TiDB](https://docs.pingcap.com/tidb/stable/overview), an open-source HTAP (Hybrid Transactional and Analytical Processing) database, to Amazon Web Services (AWS), Google Cloud, Microsoft Azure, and Alibaba Cloud. + + + + + +TiDB Cloud is a fully-managed Database-as-a-Service (DBaaS) that brings the flexibility and power of [TiDB](https://docs.pingcap.com/tidb/stable/overview), an open-source HTAP (Hybrid Transactional and Analytical Processing) database, to Amazon Web Services (AWS), Google Cloud, and Microsoft Azure. + + + +TiDB is MySQL-compatible, making it easy to migrate and work with existing applications, while offering seamless scalability to handle everything from small workloads to massive, high-performance systems. It supports both transactional (OLTP) and analytical (OLAP) workloads in one system, simplifying operations and enabling real-time insights. + +TiDB Cloud makes it easy to scale your database, handle complex management tasks, and stay focused on developing reliable, high-performing applications. + + + +- For AWS, TiDB Cloud provides **{{{ .starter }}}** for auto-scaling, cost-efficient workloads, **{{{ .essential }}}** for production-ready workloads with provisioned capacity, **{{{ .premium }}}** for mission-critical workloads that require high performance and enhanced security, and **{{{ .dedicated }}}** for enterprise-grade applications with dedicated resources and advanced capabilities. +- For Google Cloud and Azure, TiDB Cloud provides **{{{ .dedicated }}}** for enterprise-grade applications with dedicated resources and advanced capabilities. +- For Alibaba Cloud, TiDB Cloud provides **{{{ .starter }}}** for auto-scaling, cost-efficient workloads, **{{{ .essential }}}** for production-ready workloads with provisioned capacity, and **{{{ .premium }}}** for mission-critical workloads that require high performance and enhanced security. + + + + + +- For AWS, TiDB Cloud provides **{{{ .starter }}}** for auto-scaling, cost-efficient workloads, **{{{ .essential }}}** for production-ready workloads with provisioned capacity, **{{{ .premium }}}** for mission-critical workloads that require high performance and enhanced security, and **{{{ .dedicated }}}** for enterprise-grade applications with dedicated resources and advanced capabilities. +- For Google Cloud and Azure, TiDB Cloud provides **{{{ .dedicated }}}** for enterprise-grade applications with dedicated resources and advanced capabilities. + + + +## {{{ .starter }}} + +{{{ .starter }}} is a fully managed, multi-tenant TiDB offering. It delivers an instant, autoscaling MySQL-compatible database. + +The Starter plan is ideal for those who are getting started with TiDB Cloud. It provides developers and small teams with the following features: + +- **No cost**: This plan is free when usage is within the [free quota](https://www.pingcap.com/tidb-cloud-starter-pricing-details/). No credit card is required to get started. + +- **Storage**: Provides an initial 5 GiB of row-based storage and 5 GiB of columnar storage. +- **Request Units**: Includes 50 million [Request Units (RUs)](/tidb-cloud/tidb-cloud-glossary.md#request-unit-ru) for database operations. + +## {{{ .essential }}} + +For applications experiencing growing workloads and needing scalability in real time, the Essential plan provides the flexibility and performance to keep pace with your business growth with the following features: + + + +- **Enhanced capabilities**: includes all capabilities of the Starter plan, along with the capacity to handle larger and more complex workloads, as well as advanced security features. +- **Automatic scaling**: automatically adjusts storage and computing resources to efficiently meet changing workload demands. +- **Predictable pricing**: billed based on storage and Request Capacity Units (RCUs) of the compute resources, offering transparent, usage-based pricing that scales with your needs, so you only pay for what you use without surprises. + +{{{ .essential }}} offers zonal high availability, which places all components within the same availability zone to reduce network latency. For more information, see [High Availability in TiDB Cloud](/tidb-cloud/serverless-high-availability.md). + + + + + +- **Enhanced capabilities**: includes all capabilities of the Starter plan, along with the capacity to handle larger and more complex workloads, as well as advanced security features. +- **Automatic scaling**: automatically adjusts storage and computing resources to efficiently meet changing workload demands. +- **High availability**: built-in fault tolerance and redundancy ensure your applications remain available and resilient, even during infrastructure failures. +- **Predictable pricing**: billed based on storage and Request Capacity Units (RCUs) of the compute resources, offering transparent, usage-based pricing that scales with your needs, so you only pay for what you use without surprises. + +{{{ .essential }}} offers two types of high availability to address varying operational requirements. + +- Zonal High Availability: places all components within the same availability zone, which results in lower network latency. +- Regional High Availability: distributes nodes across multiple availability zones, providing maximum infrastructure isolation and redundancy. + +For more information, see [High Availability in TiDB Cloud](/tidb-cloud/serverless-high-availability.md). + + + +## {{{ .premium }}} + +For mission-critical applications that require high performance and enhanced security in a managed environment, the Premium plan provides robust infrastructure and advanced controls with the following features: + +- **Unlimited growth and auto-scaling**: provides seamless scaling to handle evolving workloads, ensuring continuous reliability for business-critical operations. +- **Performance optimization**: tuned for high-throughput and low-latency workloads, offering larger resource ceilings and more granular scaling controls. +- **Pay-as-you-go pricing**: billed based on actual [Request Capacity Unit (RCU)](/tidb-cloud/tidb-cloud-glossary.md#request-capacity-unit-rcu) consumption and storage usage. This flexible model eliminates the need for manual backend over-provisioning. +- **Advanced security**: offers deeper security configurations and compliance capabilities required by large-scale enterprises and regulated industries. + +To maximize uptime and resilience for mission-critical workloads, {{{ .premium }}} provides [Regional High Availability](/tidb-cloud/serverless-high-availability.md#regional-high-availability-architecture), which distributes nodes across multiple availability zones for greater redundancy than zonal deployments. + + + +## TiDB Cloud BYOC + +TiDB Cloud BYOC (Bring Your Own Cloud) is designed for organizations that need stronger control over data location, cloud resources, network boundaries, and compliance posture while still using TiDB Cloud as a managed service. With BYOC, the TiDB Cloud control plane is managed by PingCAP, while the TiDB data plane runs in your own cloud account. + +BYOC provides the following features: + +- **Customer-owned data plane**: keeps TiDB service resources, data storage, and network boundaries in your cloud account. +- **Managed operations**: uses TiDB Cloud for deployment, scaling, monitoring, upgrades, backup, and lifecycle management. +- **Flexible high availability**: supports both Single-AZ and Multi-AZ deployments so you can choose between lower-latency zonal deployment and higher-resilience regional deployment. +- **Cloud-account-level controls**: lets you apply your own cloud policies for networking, security, auditability, and compliance. +- **Private connectivity**: supports private network access patterns such as VPC peering, depending on your BYOC configuration. + +To meet different workload requirements, TiDB Cloud BYOC supports both Single-AZ and Multi-AZ deployments, enabling you to choose between lower-latency zonal deployment and higher-resilience deployment across multiple availability zones. + +You can set the high availability mode for each resource pool to **Zonal** or **Regional** when you [create the pool](/tidb-cloud/byoc/create-resource-pool-byoc.md). A zonal resource pool is deployed in a single availability zone, while a regional resource pool is deployed across multiple availability zones. TiDB Cloud determines the availability zone placement based on the BYOC region configuration and available cloud resources. TiDB Cloud BYOC instances created or restored in a resource pool inherit the high availability mode of the pool. After a resource pool is created, you cannot change its high availability mode or availability zone placement. + + +![TiDB Cloud BYOC Architecture](/media/tidb-cloud/byoc-architecture.png) + +A TiDB Cloud BYOC deployment includes the following major components: + +- **TiDB Cloud control plane**: provides the TiDB Cloud console, organization and project management, billing, lifecycle orchestration, monitoring views, alerting, and maintenance workflows. +- **BYOC data plane**: runs the TiDB service and related infrastructure in your cloud account. TiDB Cloud operates this environment based on the permissions granted during BYOC onboarding. +- **Resource pool**: defines the underlying physical resource, network, and capacity boundary for one or more {{{ .byoc }}} instances. Each resource pool has its own capacity configuration, resource pool CIDR, high availability mode, and AWS resource tags. +- **TiDB service VPC**: hosts TiDB service components that serve application traffic. +- **Observability service VPC**: hosts observability components used to collect metrics, logs, and operational data for the BYOC deployment. +- **Application VPC**: hosts your applications. You manage this VPC and configure network connectivity to access the BYOC TiDB service. + +Each BYOC region is deployed and operated independently. When a BYOC region is added, TiDB Cloud provisions the required regional resources in your cloud account. Because each BYOC region has its own data-plane setup, regions do not share a single TiDB Service VPC or Observability Service VPC. + +Your applications connect to a {{{ .byoc }}} instance from your application environment. Depending on your BYOC configuration, connections use either private or controlled public access. For private access, BYOC supports VPC peering and other private connectivity options. + + + +## TiDB Cloud Dedicated + +TiDB Cloud Dedicated is designed for mission-critical businesses, offering high availability across multiple availability zones, horizontal scaling, and full HTAP capabilities. + +Built on isolated cloud resources such as VPCs, VMs, managed Kubernetes services, and cloud storage, it leverages the infrastructure of major cloud providers. TiDB Cloud Dedicated clusters support the complete TiDB feature set, enabling rapid scaling, reliable backups, deployment within specific VPCs, and geographic-level disaster recovery. + +![TiDB Cloud Dedicated Architecture](/media/tidb-cloud/tidb-cloud-dedicated-architecture.png) + +## {{{ .lake }}} {#lake} + +TiDB Cloud Lake is a cloud-native data warehouse service for analytics workloads. It separates compute and storage, allowing you to provision warehouses independently, scale with workload changes, and store data cost-effectively in object storage. + +TiDB Cloud Lake supports ANSI SQL, semi-structured data processing, vector search, and AI-oriented workflows in one platform. It is designed for teams that want a managed analytics experience without operating the underlying infrastructure themselves. + +For more details, see [TiDB Cloud Lake Overview](https://docs.pingcap.com/tidbcloudlake/lake-overview/). + +## TiDB Cloud console + +The [TiDB Cloud console](https://tidbcloud.com/) is the web-based management interface for TiDB Cloud resources. It provides tools to manage TiDB Cloud resources, import or migrate data, monitor performance metrics, configure backups, set up security controls, and integrate with other cloud services, all from a single, user-friendly platform. + +## TiDB Cloud CLI (PREVIEW) + +The TiDB Cloud CLI, `ticloud`, allows you to manage {{{ .starter }}} and Essential instances directly from your terminal with simple commands. You can perform tasks such as: + +- Creating, deleting, and listing {{{ .starter }}} and Essential instances. +- Importing data into {{{ .starter }}} and Essential instances. +- Exporting data from {{{ .starter }}} and Essential instances. + +For more information, see [TiDB Cloud CLI Reference](/tidb-cloud/cli-reference.md). + +## TiDB Cloud API (PREVIEW) + +The TiDB Cloud API is a REST-based interface that provides programmatic access to manage resources across {{{ .starter }}}, {{{ .essential }}}, {{{ .premium }}}, and TiDB Cloud Dedicated. It enables automated and efficient handling of tasks such as managing projects, clusters, backups, restores, data imports, billing, and other resources in [TiDB Cloud Data Service](/tidb-cloud/data-service-overview.md). + +For more information, see [TiDB Cloud API Overview](https://docs.pingcap.com/api/tidb-cloud-api-overview). + +## Nodes + +Nodes are the core components of the TiDB architecture. TiDB nodes, TiKV nodes, and TiFlash nodes work together to process SQL queries, store data, and accelerate analytical workloads. + +- In a TiDB Cloud Dedicated cluster, you can fully manage the number and size of your dedicated TiDB, TiKV, and TiFlash nodes according to your performance requirements. For more information, see [Scalability](/tidb-cloud/scalability-concepts.md). +- In a {{{ .starter }}}, {{{ .essential }}}, or {{{ .premium }}} instance, the number and size of TiDB, TiKV, and TiFlash nodes are automatically managed. This ensures seamless scaling, eliminating the need for users to handle node configuration or management tasks. + +### TiDB node + +A [TiDB node](/tidb-computing.md) is a stateless SQL layer that connects to applications using a MySQL-compatible endpoint. It handles tasks like parsing, optimizing, and creating distributed execution plans for SQL queries. + +You can deploy multiple TiDB nodes to scale horizontally and manage higher workloads. These nodes work with load balancers, such as TiProxy or HAProxy, to provide a seamless interface. TiDB nodes do not store data themselves---they forward data requests to TiKV nodes for row-based storage or TiFlash nodes for columnar storage. + +### TiKV node + +A [TiKV node](/tikv-overview.md) is the backbone of data storage in the TiDB architecture, serving as a distributed transactional key-value storage engine that delivers reliability, scalability, and high availability. + +**Key features:** + +- **Region-based data storage** + + - Data is divided into [Regions](https://docs.pingcap.com/tidb/dev/glossary#regionpeerraft-group), each covering a specific Key Range (left-closed, right-open interval: `StartKey` to `EndKey`). + - Multiple Regions coexist within each TiKV node to ensure efficient data distribution. + +- **Transactional support** + + - TiKV nodes provide native distributed transaction support at the key-value level, ensuring Snapshot Isolation as the default isolation level. + - The TiDB node translates SQL execution plans into calls to the TiKV node API, enabling seamless SQL-level transaction support. + +- **High availability** + + - All data in TiKV nodes is replicated (default: three replicas) for durability. + - TiKV ensures native high availability and supports automatic failover, safeguarding against node failures. + +- **Scalability and reliability** + + - TiKV nodes are designed to handle expanding datasets while maintaining distributed consistency and fault tolerance. + +### TiFlash node + +A [TiFlash node](/tiflash/tiflash-overview.md) is a specialized type of storage node within the TiDB architecture. Unlike ordinary TiKV nodes, TiFlash is designed for analytical acceleration with a columnar storage model. + +**Key features:** + +- **Columnar storage** + + TiFlash nodes store data in a columnar format, making them optimized for analytical queries and significantly improving performance for read-intensive workloads. + +- **Vector search index support** + + The vector search index feature uses TiFlash replicas for tables, enabling advanced search capabilities and improving efficiency in complex analytical scenarios. + + + +## Request units and capacity in {{{ .premium }}} {#request-units-and-capacity-in-premium} + +### Request Capacity Unit (RCU) + +A [Request Capacity Unit (RCU)](/tidb-cloud/tidb-cloud-glossary.md#request-capacity-unit-rcu) is a unit of measure used to represent the provisioned compute capacity for your {{{ .premium }}} instance. One RCU provides a fixed amount of compute resources that can process a certain number of RUs per second. The number of RCUs you provision determines the baseline performance and throughput capacity of your {{{ .premium }}} instance. + +One RCU represents a sustained capacity of RUs per second. For example, a baseline of *X* RCUs guarantees *X* RUs per second on average, measured over a one-minute window (or the minimum calculation window configured for your instance). + +### RCU auto-scaling + +When configuring your {{{ .premium }}} instance, you specify the maximum number of RCUs (`RCU_max`) required for your workload. TiDB Cloud automatically scales capacity within the range of `0.25 * RCU_max` to `RCU_max`. + +For example, if you set the maximum capacity to 20,000 RCUs, TiDB Cloud dynamically scales the capacity between 5,000 and 20,000 RCUs based on real-time demand. This scaling is automatic and instantaneous, enabling you to consume up to the maximum number of RCUs at any time without manual intervention or delay. + +### RCU billing + +{{{ .premium }}} uses a usage-based billing model that charges you based on the actual Request Capacity Unit (RCU) consumption and storage usage. + +#### Per-minute calculation + +TiDB Cloud calculates your usage every minute. It measures the total number of Request Units (RUs) consumed within a 60-second window, calculates the average RUs per second, and uses this average value as the RCU consumption for that minute. This calculation ensures that your billing accurately reflects real-time traffic fluctuations. + +#### Minimum usage requirement + +To maintain baseline capacity and ensure that resources are always available for your instance, TiDB Cloud automatically sets a minimum billing RCU based on your maximum RCU setting. This value defines the baseline reserved capacity for your instance. + +If your actual consumption in a given minute is below this threshold, billing defaults to the minimum billing RCU. This mechanism ensures that your instance can immediately handle sudden traffic spikes up to your specified maximum, without performance degradation or delays. + +### Request Unit (RU) + +A [Request Unit (RU)](/tidb-cloud/tidb-cloud-glossary.md#request-unit-ru) is a unit of measure used to represent the resources consumed by a single request to the database. The number of RUs consumed by a request depends on factors such as the operation type and the amount of data retrieved or modified. + +{{{ .premium }}} normalizes the cost of all database operations using Request Units and measures this cost based on throughput (Request Units per second, RU/s). This unified metric makes your throughput costs predictable, helping you manage your application costs more effectively. + +#### Baseline performance examples + +The following table lists baseline performance examples for common operations to help you estimate your workload. + +| Operation type | Description | Estimated cost | +|----------------|------------------------------------------|----------------| +| Point read | Reading a 1 KiB item by its unique ID | 1.5 RU | +| OLTP write | Standard Sysbench model (1 KiB item size) | 2.5 RU | + +> **Note:** +> +> A point read is the most efficient way to retrieve data by its unique ID. For write operations, the RU cost accounts for the I/O and indexing effort required to persist the data. RU consumption scales proportionally with the data size and operation complexity. + +### Request Unit considerations + +TiDB Cloud calculates the total RU charge for any operation based on the database effort required to execute it. The calculation considers the following dimensions: + +- **Data access and size** + + - **Read and write volume**: RUs scale directly with the size of the data payload. Processing a 100 KiB record consumes more RUs than a 1 KiB record. + - **Read and write rows**: the number of rows involved in an operation is a primary cost driver. Even with small payloads, querying or updating multiple rows increases the total RU consumption because each row requires processing, locking, and validation. + - **Indexing impact**: + + - **Writes**: each affected index on a table must be updated during a write operation. Tables with more indexes incur higher RU costs for `INSERT`, `UPDATE`, and `DELETE` operations. + - **Reads**: well-designed indexes significantly reduce query RUs by enabling the engine to locate rows efficiently and avoid full-table scans. + +- **Query complexity** + + - **Scanning efficiency**: RU consumption is heavily influenced by the number of rows that the engine must scan. + + - **Read metrics (estimated rows)**: a point read that uses a primary key or unique index is the most efficient operation. A query that scans millions of rows consumes significantly more RUs than a query that uses an optimized index. + + - **Write metrics (affected rows)**: the RU cost for data modification is tied to the number of affected rows. Modifying 10,000 rows in a single statement results in a much higher charge than modifying a single row. + + - **Computational logic**: complex SQL operations, including multiple table joins, deep subqueries, and aggregations, require more CPU cycles to compute execution paths and process data. + + diff --git a/tidb-cloud/byoc/create-resource-pool-byoc.md b/tidb-cloud/byoc/create-resource-pool-byoc.md index edcf08542135b..c3a995569cd58 100644 --- a/tidb-cloud/byoc/create-resource-pool-byoc.md +++ b/tidb-cloud/byoc/create-resource-pool-byoc.md @@ -56,7 +56,7 @@ To create a resource pool, take the following steps: >**Note:** > > - You must select a high availability mode before creating the resource pool. -> - If you select the **Regional** mode, make sure that the region for this pool contains at least three eligible availability zones. If this requirement is not met, the process of creating the regional resource pool might get stuck. +> - If you select the **Regional** mode, make sure that the region for this pool contains at least three eligible availability zones. If this requirement is not met, the process of creating the regional resource pool might fail to complete. > - TiDB Cloud determines the availability zones based on the [BYOC region configuration](/tidb-cloud/byoc/byoc-prepare-environment-aws.md#step-3-select-region-and-availability-zones-azs) and available cloud resources. After the resource pool is created, you cannot change its high availability mode or availability zone placement. diff --git a/tidb-cloud/premium/backup-and-restore-premium.md b/tidb-cloud/premium/backup-and-restore-premium.md index a38d9199cb860..bdaa473df7f72 100644 --- a/tidb-cloud/premium/backup-and-restore-premium.md +++ b/tidb-cloud/premium/backup-and-restore-premium.md @@ -242,7 +242,7 @@ To restore your data to a new {{{ .premium }}} or {{{ - For {{{ .byoc }}}, select an active resource pool in the same cloud provider and region as the backup. The restored instance inherits the high availability mode of the selected resource pool. You can restore the same backup to a Zonal or Regional resource pool. If no suitable resource pool is available, an `Organization Owner` can create one before restoring the instance. Other roles cannot create resource pools. For more information, see [Create a Resource Pool](/tidb-cloud/byoc/create-resource-pool-byoc.md). + For {{{ .byoc }}}, select an active resource pool in the same cloud provider and region as the backup. The restored instance inherits the high availability mode of the selected resource pool. You can restore the same backup to a zonal or regional resource pool. If no suitable resource pool is available, an `Organization Owner` can create one before restoring the instance. Other roles cannot create resource pools. For more information, see [Create a Resource Pool](/tidb-cloud/byoc/create-resource-pool-byoc.md). If the selected resource pool has a Pool vCPU Limit and its current provisioned vCPU is greater than or equal to the limit, TiDB Cloud displays a warning and you cannot restore the instance to that resource pool. To continue, go to the Resource Pool details page to increase or turn off the Pool vCPU Limit, or select another resource pool. @@ -372,7 +372,7 @@ To restore backups from cloud storage, do the following: - For {{{ .byoc }}}, select an active resource pool that matches the target cloud provider and region. The restored instance inherits the high availability mode of the selected resource pool. You can restore the same backup to a Zonal or Regional resource pool. If no suitable resource pool is available, an `Organization Owner` can create one before restoring the instance. Other roles cannot create resource pools. For more information, see [Create a Resource Pool](/tidb-cloud/byoc/create-resource-pool-byoc.md). + For {{{ .byoc }}}, select an active resource pool that matches the target cloud provider and region. The restored instance inherits the high availability mode of the selected resource pool. You can restore the same backup to a zonal or regional resource pool. If no suitable resource pool is available, an `Organization Owner` can create one before restoring the instance. Other roles cannot create resource pools. For more information, see [Create a Resource Pool](/tidb-cloud/byoc/create-resource-pool-byoc.md). If the selected resource pool has a Pool vCPU Limit and its current provisioned vCPU is greater than or equal to the limit, TiDB Cloud displays a warning and you cannot restore the instance to that resource pool. To continue, go to the Resource Pool details page to increase or turn off the Pool vCPU Limit, or select another resource pool. From 34631ad40cb25d61db352063bd494432969edb00 Mon Sep 17 00:00:00 2001 From: qiancai Date: Wed, 26 Aug 2026 09:38:32 +0800 Subject: [PATCH 19/20] docs: normalize line endings for architecture concepts --- tidb-cloud/architecture-concepts.md | 574 ++++++++++++++-------------- 1 file changed, 287 insertions(+), 287 deletions(-) diff --git a/tidb-cloud/architecture-concepts.md b/tidb-cloud/architecture-concepts.md index 597058d76b779..8c90ab295971e 100644 --- a/tidb-cloud/architecture-concepts.md +++ b/tidb-cloud/architecture-concepts.md @@ -1,287 +1,287 @@ ---- -title: Architecture -summary: Learn about architecture concepts for TiDB Cloud. ---- - -# Architecture - - - -TiDB Cloud is a fully-managed Database-as-a-Service (DBaaS) that brings the flexibility and power of [TiDB](https://docs.pingcap.com/tidb/stable/overview), an open-source HTAP (Hybrid Transactional and Analytical Processing) database, to Amazon Web Services (AWS), Google Cloud, Microsoft Azure, and Alibaba Cloud. - - - - - -TiDB Cloud is a fully-managed Database-as-a-Service (DBaaS) that brings the flexibility and power of [TiDB](https://docs.pingcap.com/tidb/stable/overview), an open-source HTAP (Hybrid Transactional and Analytical Processing) database, to Amazon Web Services (AWS), Google Cloud, and Microsoft Azure. - - - -TiDB is MySQL-compatible, making it easy to migrate and work with existing applications, while offering seamless scalability to handle everything from small workloads to massive, high-performance systems. It supports both transactional (OLTP) and analytical (OLAP) workloads in one system, simplifying operations and enabling real-time insights. - -TiDB Cloud makes it easy to scale your database, handle complex management tasks, and stay focused on developing reliable, high-performing applications. - - - -- For AWS, TiDB Cloud provides **{{{ .starter }}}** for auto-scaling, cost-efficient workloads, **{{{ .essential }}}** for production-ready workloads with provisioned capacity, **{{{ .premium }}}** for mission-critical workloads that require high performance and enhanced security, and **{{{ .dedicated }}}** for enterprise-grade applications with dedicated resources and advanced capabilities. -- For Google Cloud and Azure, TiDB Cloud provides **{{{ .dedicated }}}** for enterprise-grade applications with dedicated resources and advanced capabilities. -- For Alibaba Cloud, TiDB Cloud provides **{{{ .starter }}}** for auto-scaling, cost-efficient workloads, **{{{ .essential }}}** for production-ready workloads with provisioned capacity, and **{{{ .premium }}}** for mission-critical workloads that require high performance and enhanced security. - - - - - -- For AWS, TiDB Cloud provides **{{{ .starter }}}** for auto-scaling, cost-efficient workloads, **{{{ .essential }}}** for production-ready workloads with provisioned capacity, **{{{ .premium }}}** for mission-critical workloads that require high performance and enhanced security, and **{{{ .dedicated }}}** for enterprise-grade applications with dedicated resources and advanced capabilities. -- For Google Cloud and Azure, TiDB Cloud provides **{{{ .dedicated }}}** for enterprise-grade applications with dedicated resources and advanced capabilities. - - - -## {{{ .starter }}} - -{{{ .starter }}} is a fully managed, multi-tenant TiDB offering. It delivers an instant, autoscaling MySQL-compatible database. - -The Starter plan is ideal for those who are getting started with TiDB Cloud. It provides developers and small teams with the following features: - -- **No cost**: This plan is free when usage is within the [free quota](https://www.pingcap.com/tidb-cloud-starter-pricing-details/). No credit card is required to get started. - -- **Storage**: Provides an initial 5 GiB of row-based storage and 5 GiB of columnar storage. -- **Request Units**: Includes 50 million [Request Units (RUs)](/tidb-cloud/tidb-cloud-glossary.md#request-unit-ru) for database operations. - -## {{{ .essential }}} - -For applications experiencing growing workloads and needing scalability in real time, the Essential plan provides the flexibility and performance to keep pace with your business growth with the following features: - - - -- **Enhanced capabilities**: includes all capabilities of the Starter plan, along with the capacity to handle larger and more complex workloads, as well as advanced security features. -- **Automatic scaling**: automatically adjusts storage and computing resources to efficiently meet changing workload demands. -- **Predictable pricing**: billed based on storage and Request Capacity Units (RCUs) of the compute resources, offering transparent, usage-based pricing that scales with your needs, so you only pay for what you use without surprises. - -{{{ .essential }}} offers zonal high availability, which places all components within the same availability zone to reduce network latency. For more information, see [High Availability in TiDB Cloud](/tidb-cloud/serverless-high-availability.md). - - - - - -- **Enhanced capabilities**: includes all capabilities of the Starter plan, along with the capacity to handle larger and more complex workloads, as well as advanced security features. -- **Automatic scaling**: automatically adjusts storage and computing resources to efficiently meet changing workload demands. -- **High availability**: built-in fault tolerance and redundancy ensure your applications remain available and resilient, even during infrastructure failures. -- **Predictable pricing**: billed based on storage and Request Capacity Units (RCUs) of the compute resources, offering transparent, usage-based pricing that scales with your needs, so you only pay for what you use without surprises. - -{{{ .essential }}} offers two types of high availability to address varying operational requirements. - -- Zonal High Availability: places all components within the same availability zone, which results in lower network latency. -- Regional High Availability: distributes nodes across multiple availability zones, providing maximum infrastructure isolation and redundancy. - -For more information, see [High Availability in TiDB Cloud](/tidb-cloud/serverless-high-availability.md). - - - -## {{{ .premium }}} - -For mission-critical applications that require high performance and enhanced security in a managed environment, the Premium plan provides robust infrastructure and advanced controls with the following features: - -- **Unlimited growth and auto-scaling**: provides seamless scaling to handle evolving workloads, ensuring continuous reliability for business-critical operations. -- **Performance optimization**: tuned for high-throughput and low-latency workloads, offering larger resource ceilings and more granular scaling controls. -- **Pay-as-you-go pricing**: billed based on actual [Request Capacity Unit (RCU)](/tidb-cloud/tidb-cloud-glossary.md#request-capacity-unit-rcu) consumption and storage usage. This flexible model eliminates the need for manual backend over-provisioning. -- **Advanced security**: offers deeper security configurations and compliance capabilities required by large-scale enterprises and regulated industries. - -To maximize uptime and resilience for mission-critical workloads, {{{ .premium }}} provides [Regional High Availability](/tidb-cloud/serverless-high-availability.md#regional-high-availability-architecture), which distributes nodes across multiple availability zones for greater redundancy than zonal deployments. - - - -## TiDB Cloud BYOC - -TiDB Cloud BYOC (Bring Your Own Cloud) is designed for organizations that need stronger control over data location, cloud resources, network boundaries, and compliance posture while still using TiDB Cloud as a managed service. With BYOC, the TiDB Cloud control plane is managed by PingCAP, while the TiDB data plane runs in your own cloud account. - -BYOC provides the following features: - -- **Customer-owned data plane**: keeps TiDB service resources, data storage, and network boundaries in your cloud account. -- **Managed operations**: uses TiDB Cloud for deployment, scaling, monitoring, upgrades, backup, and lifecycle management. -- **Flexible high availability**: supports both Single-AZ and Multi-AZ deployments so you can choose between lower-latency zonal deployment and higher-resilience regional deployment. -- **Cloud-account-level controls**: lets you apply your own cloud policies for networking, security, auditability, and compliance. -- **Private connectivity**: supports private network access patterns such as VPC peering, depending on your BYOC configuration. - -To meet different workload requirements, TiDB Cloud BYOC supports both Single-AZ and Multi-AZ deployments, enabling you to choose between lower-latency zonal deployment and higher-resilience deployment across multiple availability zones. - -You can set the high availability mode for each resource pool to **Zonal** or **Regional** when you [create the pool](/tidb-cloud/byoc/create-resource-pool-byoc.md). A zonal resource pool is deployed in a single availability zone, while a regional resource pool is deployed across multiple availability zones. TiDB Cloud determines the availability zone placement based on the BYOC region configuration and available cloud resources. TiDB Cloud BYOC instances created or restored in a resource pool inherit the high availability mode of the pool. After a resource pool is created, you cannot change its high availability mode or availability zone placement. - - -![TiDB Cloud BYOC Architecture](/media/tidb-cloud/byoc-architecture.png) - -A TiDB Cloud BYOC deployment includes the following major components: - -- **TiDB Cloud control plane**: provides the TiDB Cloud console, organization and project management, billing, lifecycle orchestration, monitoring views, alerting, and maintenance workflows. -- **BYOC data plane**: runs the TiDB service and related infrastructure in your cloud account. TiDB Cloud operates this environment based on the permissions granted during BYOC onboarding. -- **Resource pool**: defines the underlying physical resource, network, and capacity boundary for one or more {{{ .byoc }}} instances. Each resource pool has its own capacity configuration, resource pool CIDR, high availability mode, and AWS resource tags. -- **TiDB service VPC**: hosts TiDB service components that serve application traffic. -- **Observability service VPC**: hosts observability components used to collect metrics, logs, and operational data for the BYOC deployment. -- **Application VPC**: hosts your applications. You manage this VPC and configure network connectivity to access the BYOC TiDB service. - -Each BYOC region is deployed and operated independently. When a BYOC region is added, TiDB Cloud provisions the required regional resources in your cloud account. Because each BYOC region has its own data-plane setup, regions do not share a single TiDB Service VPC or Observability Service VPC. - -Your applications connect to a {{{ .byoc }}} instance from your application environment. Depending on your BYOC configuration, connections use either private or controlled public access. For private access, BYOC supports VPC peering and other private connectivity options. - - - -## TiDB Cloud Dedicated - -TiDB Cloud Dedicated is designed for mission-critical businesses, offering high availability across multiple availability zones, horizontal scaling, and full HTAP capabilities. - -Built on isolated cloud resources such as VPCs, VMs, managed Kubernetes services, and cloud storage, it leverages the infrastructure of major cloud providers. TiDB Cloud Dedicated clusters support the complete TiDB feature set, enabling rapid scaling, reliable backups, deployment within specific VPCs, and geographic-level disaster recovery. - -![TiDB Cloud Dedicated Architecture](/media/tidb-cloud/tidb-cloud-dedicated-architecture.png) - -## {{{ .lake }}} {#lake} - -TiDB Cloud Lake is a cloud-native data warehouse service for analytics workloads. It separates compute and storage, allowing you to provision warehouses independently, scale with workload changes, and store data cost-effectively in object storage. - -TiDB Cloud Lake supports ANSI SQL, semi-structured data processing, vector search, and AI-oriented workflows in one platform. It is designed for teams that want a managed analytics experience without operating the underlying infrastructure themselves. - -For more details, see [TiDB Cloud Lake Overview](https://docs.pingcap.com/tidbcloudlake/lake-overview/). - -## TiDB Cloud console - -The [TiDB Cloud console](https://tidbcloud.com/) is the web-based management interface for TiDB Cloud resources. It provides tools to manage TiDB Cloud resources, import or migrate data, monitor performance metrics, configure backups, set up security controls, and integrate with other cloud services, all from a single, user-friendly platform. - -## TiDB Cloud CLI (PREVIEW) - -The TiDB Cloud CLI, `ticloud`, allows you to manage {{{ .starter }}} and Essential instances directly from your terminal with simple commands. You can perform tasks such as: - -- Creating, deleting, and listing {{{ .starter }}} and Essential instances. -- Importing data into {{{ .starter }}} and Essential instances. -- Exporting data from {{{ .starter }}} and Essential instances. - -For more information, see [TiDB Cloud CLI Reference](/tidb-cloud/cli-reference.md). - -## TiDB Cloud API (PREVIEW) - -The TiDB Cloud API is a REST-based interface that provides programmatic access to manage resources across {{{ .starter }}}, {{{ .essential }}}, {{{ .premium }}}, and TiDB Cloud Dedicated. It enables automated and efficient handling of tasks such as managing projects, clusters, backups, restores, data imports, billing, and other resources in [TiDB Cloud Data Service](/tidb-cloud/data-service-overview.md). - -For more information, see [TiDB Cloud API Overview](https://docs.pingcap.com/api/tidb-cloud-api-overview). - -## Nodes - -Nodes are the core components of the TiDB architecture. TiDB nodes, TiKV nodes, and TiFlash nodes work together to process SQL queries, store data, and accelerate analytical workloads. - -- In a TiDB Cloud Dedicated cluster, you can fully manage the number and size of your dedicated TiDB, TiKV, and TiFlash nodes according to your performance requirements. For more information, see [Scalability](/tidb-cloud/scalability-concepts.md). -- In a {{{ .starter }}}, {{{ .essential }}}, or {{{ .premium }}} instance, the number and size of TiDB, TiKV, and TiFlash nodes are automatically managed. This ensures seamless scaling, eliminating the need for users to handle node configuration or management tasks. - -### TiDB node - -A [TiDB node](/tidb-computing.md) is a stateless SQL layer that connects to applications using a MySQL-compatible endpoint. It handles tasks like parsing, optimizing, and creating distributed execution plans for SQL queries. - -You can deploy multiple TiDB nodes to scale horizontally and manage higher workloads. These nodes work with load balancers, such as TiProxy or HAProxy, to provide a seamless interface. TiDB nodes do not store data themselves---they forward data requests to TiKV nodes for row-based storage or TiFlash nodes for columnar storage. - -### TiKV node - -A [TiKV node](/tikv-overview.md) is the backbone of data storage in the TiDB architecture, serving as a distributed transactional key-value storage engine that delivers reliability, scalability, and high availability. - -**Key features:** - -- **Region-based data storage** - - - Data is divided into [Regions](https://docs.pingcap.com/tidb/dev/glossary#regionpeerraft-group), each covering a specific Key Range (left-closed, right-open interval: `StartKey` to `EndKey`). - - Multiple Regions coexist within each TiKV node to ensure efficient data distribution. - -- **Transactional support** - - - TiKV nodes provide native distributed transaction support at the key-value level, ensuring Snapshot Isolation as the default isolation level. - - The TiDB node translates SQL execution plans into calls to the TiKV node API, enabling seamless SQL-level transaction support. - -- **High availability** - - - All data in TiKV nodes is replicated (default: three replicas) for durability. - - TiKV ensures native high availability and supports automatic failover, safeguarding against node failures. - -- **Scalability and reliability** - - - TiKV nodes are designed to handle expanding datasets while maintaining distributed consistency and fault tolerance. - -### TiFlash node - -A [TiFlash node](/tiflash/tiflash-overview.md) is a specialized type of storage node within the TiDB architecture. Unlike ordinary TiKV nodes, TiFlash is designed for analytical acceleration with a columnar storage model. - -**Key features:** - -- **Columnar storage** - - TiFlash nodes store data in a columnar format, making them optimized for analytical queries and significantly improving performance for read-intensive workloads. - -- **Vector search index support** - - The vector search index feature uses TiFlash replicas for tables, enabling advanced search capabilities and improving efficiency in complex analytical scenarios. - - - -## Request units and capacity in {{{ .premium }}} {#request-units-and-capacity-in-premium} - -### Request Capacity Unit (RCU) - -A [Request Capacity Unit (RCU)](/tidb-cloud/tidb-cloud-glossary.md#request-capacity-unit-rcu) is a unit of measure used to represent the provisioned compute capacity for your {{{ .premium }}} instance. One RCU provides a fixed amount of compute resources that can process a certain number of RUs per second. The number of RCUs you provision determines the baseline performance and throughput capacity of your {{{ .premium }}} instance. - -One RCU represents a sustained capacity of RUs per second. For example, a baseline of *X* RCUs guarantees *X* RUs per second on average, measured over a one-minute window (or the minimum calculation window configured for your instance). - -### RCU auto-scaling - -When configuring your {{{ .premium }}} instance, you specify the maximum number of RCUs (`RCU_max`) required for your workload. TiDB Cloud automatically scales capacity within the range of `0.25 * RCU_max` to `RCU_max`. - -For example, if you set the maximum capacity to 20,000 RCUs, TiDB Cloud dynamically scales the capacity between 5,000 and 20,000 RCUs based on real-time demand. This scaling is automatic and instantaneous, enabling you to consume up to the maximum number of RCUs at any time without manual intervention or delay. - -### RCU billing - -{{{ .premium }}} uses a usage-based billing model that charges you based on the actual Request Capacity Unit (RCU) consumption and storage usage. - -#### Per-minute calculation - -TiDB Cloud calculates your usage every minute. It measures the total number of Request Units (RUs) consumed within a 60-second window, calculates the average RUs per second, and uses this average value as the RCU consumption for that minute. This calculation ensures that your billing accurately reflects real-time traffic fluctuations. - -#### Minimum usage requirement - -To maintain baseline capacity and ensure that resources are always available for your instance, TiDB Cloud automatically sets a minimum billing RCU based on your maximum RCU setting. This value defines the baseline reserved capacity for your instance. - -If your actual consumption in a given minute is below this threshold, billing defaults to the minimum billing RCU. This mechanism ensures that your instance can immediately handle sudden traffic spikes up to your specified maximum, without performance degradation or delays. - -### Request Unit (RU) - -A [Request Unit (RU)](/tidb-cloud/tidb-cloud-glossary.md#request-unit-ru) is a unit of measure used to represent the resources consumed by a single request to the database. The number of RUs consumed by a request depends on factors such as the operation type and the amount of data retrieved or modified. - -{{{ .premium }}} normalizes the cost of all database operations using Request Units and measures this cost based on throughput (Request Units per second, RU/s). This unified metric makes your throughput costs predictable, helping you manage your application costs more effectively. - -#### Baseline performance examples - -The following table lists baseline performance examples for common operations to help you estimate your workload. - -| Operation type | Description | Estimated cost | -|----------------|------------------------------------------|----------------| -| Point read | Reading a 1 KiB item by its unique ID | 1.5 RU | -| OLTP write | Standard Sysbench model (1 KiB item size) | 2.5 RU | - -> **Note:** -> -> A point read is the most efficient way to retrieve data by its unique ID. For write operations, the RU cost accounts for the I/O and indexing effort required to persist the data. RU consumption scales proportionally with the data size and operation complexity. - -### Request Unit considerations - -TiDB Cloud calculates the total RU charge for any operation based on the database effort required to execute it. The calculation considers the following dimensions: - -- **Data access and size** - - - **Read and write volume**: RUs scale directly with the size of the data payload. Processing a 100 KiB record consumes more RUs than a 1 KiB record. - - **Read and write rows**: the number of rows involved in an operation is a primary cost driver. Even with small payloads, querying or updating multiple rows increases the total RU consumption because each row requires processing, locking, and validation. - - **Indexing impact**: - - - **Writes**: each affected index on a table must be updated during a write operation. Tables with more indexes incur higher RU costs for `INSERT`, `UPDATE`, and `DELETE` operations. - - **Reads**: well-designed indexes significantly reduce query RUs by enabling the engine to locate rows efficiently and avoid full-table scans. - -- **Query complexity** - - - **Scanning efficiency**: RU consumption is heavily influenced by the number of rows that the engine must scan. - - - **Read metrics (estimated rows)**: a point read that uses a primary key or unique index is the most efficient operation. A query that scans millions of rows consumes significantly more RUs than a query that uses an optimized index. - - - **Write metrics (affected rows)**: the RU cost for data modification is tied to the number of affected rows. Modifying 10,000 rows in a single statement results in a much higher charge than modifying a single row. - - - **Computational logic**: complex SQL operations, including multiple table joins, deep subqueries, and aggregations, require more CPU cycles to compute execution paths and process data. - - +--- +title: Architecture +summary: Learn about architecture concepts for TiDB Cloud. +--- + +# Architecture + + + +TiDB Cloud is a fully-managed Database-as-a-Service (DBaaS) that brings the flexibility and power of [TiDB](https://docs.pingcap.com/tidb/stable/overview), an open-source HTAP (Hybrid Transactional and Analytical Processing) database, to Amazon Web Services (AWS), Google Cloud, Microsoft Azure, and Alibaba Cloud. + + + + + +TiDB Cloud is a fully-managed Database-as-a-Service (DBaaS) that brings the flexibility and power of [TiDB](https://docs.pingcap.com/tidb/stable/overview), an open-source HTAP (Hybrid Transactional and Analytical Processing) database, to Amazon Web Services (AWS), Google Cloud, and Microsoft Azure. + + + +TiDB is MySQL-compatible, making it easy to migrate and work with existing applications, while offering seamless scalability to handle everything from small workloads to massive, high-performance systems. It supports both transactional (OLTP) and analytical (OLAP) workloads in one system, simplifying operations and enabling real-time insights. + +TiDB Cloud makes it easy to scale your database, handle complex management tasks, and stay focused on developing reliable, high-performing applications. + + + +- For AWS, TiDB Cloud provides **{{{ .starter }}}** for auto-scaling, cost-efficient workloads, **{{{ .essential }}}** for production-ready workloads with provisioned capacity, **{{{ .premium }}}** for mission-critical workloads that require high performance and enhanced security, and **{{{ .dedicated }}}** for enterprise-grade applications with dedicated resources and advanced capabilities. +- For Google Cloud and Azure, TiDB Cloud provides **{{{ .dedicated }}}** for enterprise-grade applications with dedicated resources and advanced capabilities. +- For Alibaba Cloud, TiDB Cloud provides **{{{ .starter }}}** for auto-scaling, cost-efficient workloads, **{{{ .essential }}}** for production-ready workloads with provisioned capacity, and **{{{ .premium }}}** for mission-critical workloads that require high performance and enhanced security. + + + + + +- For AWS, TiDB Cloud provides **{{{ .starter }}}** for auto-scaling, cost-efficient workloads, **{{{ .essential }}}** for production-ready workloads with provisioned capacity, **{{{ .premium }}}** for mission-critical workloads that require high performance and enhanced security, and **{{{ .dedicated }}}** for enterprise-grade applications with dedicated resources and advanced capabilities. +- For Google Cloud and Azure, TiDB Cloud provides **{{{ .dedicated }}}** for enterprise-grade applications with dedicated resources and advanced capabilities. + + + +## {{{ .starter }}} + +{{{ .starter }}} is a fully managed, multi-tenant TiDB offering. It delivers an instant, autoscaling MySQL-compatible database. + +The Starter plan is ideal for those who are getting started with TiDB Cloud. It provides developers and small teams with the following features: + +- **No cost**: This plan is free when usage is within the [free quota](https://www.pingcap.com/tidb-cloud-starter-pricing-details/). No credit card is required to get started. + +- **Storage**: Provides an initial 5 GiB of row-based storage and 5 GiB of columnar storage. +- **Request Units**: Includes 50 million [Request Units (RUs)](/tidb-cloud/tidb-cloud-glossary.md#request-unit-ru) for database operations. + +## {{{ .essential }}} + +For applications experiencing growing workloads and needing scalability in real time, the Essential plan provides the flexibility and performance to keep pace with your business growth with the following features: + + + +- **Enhanced capabilities**: includes all capabilities of the Starter plan, along with the capacity to handle larger and more complex workloads, as well as advanced security features. +- **Automatic scaling**: automatically adjusts storage and computing resources to efficiently meet changing workload demands. +- **Predictable pricing**: billed based on storage and Request Capacity Units (RCUs) of the compute resources, offering transparent, usage-based pricing that scales with your needs, so you only pay for what you use without surprises. + +{{{ .essential }}} offers zonal high availability, which places all components within the same availability zone to reduce network latency. For more information, see [High Availability in TiDB Cloud](/tidb-cloud/serverless-high-availability.md). + + + + + +- **Enhanced capabilities**: includes all capabilities of the Starter plan, along with the capacity to handle larger and more complex workloads, as well as advanced security features. +- **Automatic scaling**: automatically adjusts storage and computing resources to efficiently meet changing workload demands. +- **High availability**: built-in fault tolerance and redundancy ensure your applications remain available and resilient, even during infrastructure failures. +- **Predictable pricing**: billed based on storage and Request Capacity Units (RCUs) of the compute resources, offering transparent, usage-based pricing that scales with your needs, so you only pay for what you use without surprises. + +{{{ .essential }}} offers two types of high availability to address varying operational requirements. + +- Zonal High Availability: places all components within the same availability zone, which results in lower network latency. +- Regional High Availability: distributes nodes across multiple availability zones, providing maximum infrastructure isolation and redundancy. + +For more information, see [High Availability in TiDB Cloud](/tidb-cloud/serverless-high-availability.md). + + + +## {{{ .premium }}} + +For mission-critical applications that require high performance and enhanced security in a managed environment, the Premium plan provides robust infrastructure and advanced controls with the following features: + +- **Unlimited growth and auto-scaling**: provides seamless scaling to handle evolving workloads, ensuring continuous reliability for business-critical operations. +- **Performance optimization**: tuned for high-throughput and low-latency workloads, offering larger resource ceilings and more granular scaling controls. +- **Pay-as-you-go pricing**: billed based on actual [Request Capacity Unit (RCU)](/tidb-cloud/tidb-cloud-glossary.md#request-capacity-unit-rcu) consumption and storage usage. This flexible model eliminates the need for manual backend over-provisioning. +- **Advanced security**: offers deeper security configurations and compliance capabilities required by large-scale enterprises and regulated industries. + +To maximize uptime and resilience for mission-critical workloads, {{{ .premium }}} provides [Regional High Availability](/tidb-cloud/serverless-high-availability.md#regional-high-availability-architecture), which distributes nodes across multiple availability zones for greater redundancy than zonal deployments. + + + +## TiDB Cloud BYOC + +TiDB Cloud BYOC (Bring Your Own Cloud) is designed for organizations that need stronger control over data location, cloud resources, network boundaries, and compliance posture while still using TiDB Cloud as a managed service. With BYOC, the TiDB Cloud control plane is managed by PingCAP, while the TiDB data plane runs in your own cloud account. + +BYOC provides the following features: + +- **Customer-owned data plane**: keeps TiDB service resources, data storage, and network boundaries in your cloud account. +- **Managed operations**: uses TiDB Cloud for deployment, scaling, monitoring, upgrades, backup, and lifecycle management. +- **Flexible high availability**: supports both Single-AZ and Multi-AZ deployments so you can choose between lower-latency zonal deployment and higher-resilience regional deployment. +- **Cloud-account-level controls**: lets you apply your own cloud policies for networking, security, auditability, and compliance. +- **Private connectivity**: supports private network access patterns such as VPC peering, depending on your BYOC configuration. + +To meet different workload requirements, TiDB Cloud BYOC supports both Single-AZ and Multi-AZ deployments, enabling you to choose between lower-latency zonal deployment and higher-resilience deployment across multiple availability zones. + +You can set the high availability mode for each resource pool to **Zonal** or **Regional** when you [create the pool](/tidb-cloud/byoc/create-resource-pool-byoc.md). A zonal resource pool is deployed in a single availability zone, while a regional resource pool is deployed across multiple availability zones. TiDB Cloud determines the availability zone placement based on the BYOC region configuration and available cloud resources. TiDB Cloud BYOC instances created or restored in a resource pool inherit the high availability mode of the pool. After a resource pool is created, you cannot change its high availability mode or availability zone placement. + + +![TiDB Cloud BYOC Architecture](/media/tidb-cloud/byoc-architecture.png) + +A TiDB Cloud BYOC deployment includes the following major components: + +- **TiDB Cloud control plane**: provides the TiDB Cloud console, organization and project management, billing, lifecycle orchestration, monitoring views, alerting, and maintenance workflows. +- **BYOC data plane**: runs the TiDB service and related infrastructure in your cloud account. TiDB Cloud operates this environment based on the permissions granted during BYOC onboarding. +- **Resource pool**: defines the underlying physical resource, network, and capacity boundary for one or more {{{ .byoc }}} instances. Each resource pool has its own capacity configuration, resource pool CIDR, high availability mode, and AWS resource tags. +- **TiDB service VPC**: hosts TiDB service components that serve application traffic. +- **Observability service VPC**: hosts observability components used to collect metrics, logs, and operational data for the BYOC deployment. +- **Application VPC**: hosts your applications. You manage this VPC and configure network connectivity to access the BYOC TiDB service. + +Each BYOC region is deployed and operated independently. When a BYOC region is added, TiDB Cloud provisions the required regional resources in your cloud account. Because each BYOC region has its own data-plane setup, regions do not share a single TiDB Service VPC or Observability Service VPC. + +Your applications connect to a {{{ .byoc }}} instance from your application environment. Depending on your BYOC configuration, connections use either private or controlled public access. For private access, BYOC supports VPC peering and other private connectivity options. + + + +## TiDB Cloud Dedicated + +TiDB Cloud Dedicated is designed for mission-critical businesses, offering high availability across multiple availability zones, horizontal scaling, and full HTAP capabilities. + +Built on isolated cloud resources such as VPCs, VMs, managed Kubernetes services, and cloud storage, it leverages the infrastructure of major cloud providers. TiDB Cloud Dedicated clusters support the complete TiDB feature set, enabling rapid scaling, reliable backups, deployment within specific VPCs, and geographic-level disaster recovery. + +![TiDB Cloud Dedicated Architecture](/media/tidb-cloud/tidb-cloud-dedicated-architecture.png) + +## {{{ .lake }}} {#lake} + +TiDB Cloud Lake is a cloud-native data warehouse service for analytics workloads. It separates compute and storage, allowing you to provision warehouses independently, scale with workload changes, and store data cost-effectively in object storage. + +TiDB Cloud Lake supports ANSI SQL, semi-structured data processing, vector search, and AI-oriented workflows in one platform. It is designed for teams that want a managed analytics experience without operating the underlying infrastructure themselves. + +For more details, see [TiDB Cloud Lake Overview](https://docs.pingcap.com/tidbcloudlake/lake-overview/). + +## TiDB Cloud console + +The [TiDB Cloud console](https://tidbcloud.com/) is the web-based management interface for TiDB Cloud resources. It provides tools to manage TiDB Cloud resources, import or migrate data, monitor performance metrics, configure backups, set up security controls, and integrate with other cloud services, all from a single, user-friendly platform. + +## TiDB Cloud CLI (PREVIEW) + +The TiDB Cloud CLI, `ticloud`, allows you to manage {{{ .starter }}} and Essential instances directly from your terminal with simple commands. You can perform tasks such as: + +- Creating, deleting, and listing {{{ .starter }}} and Essential instances. +- Importing data into {{{ .starter }}} and Essential instances. +- Exporting data from {{{ .starter }}} and Essential instances. + +For more information, see [TiDB Cloud CLI Reference](/tidb-cloud/cli-reference.md). + +## TiDB Cloud API (PREVIEW) + +The TiDB Cloud API is a REST-based interface that provides programmatic access to manage resources across {{{ .starter }}}, {{{ .essential }}}, {{{ .premium }}}, and TiDB Cloud Dedicated. It enables automated and efficient handling of tasks such as managing projects, clusters, backups, restores, data imports, billing, and other resources in [TiDB Cloud Data Service](/tidb-cloud/data-service-overview.md). + +For more information, see [TiDB Cloud API Overview](https://docs.pingcap.com/api/tidb-cloud-api-overview). + +## Nodes + +Nodes are the core components of the TiDB architecture. TiDB nodes, TiKV nodes, and TiFlash nodes work together to process SQL queries, store data, and accelerate analytical workloads. + +- In a TiDB Cloud Dedicated cluster, you can fully manage the number and size of your dedicated TiDB, TiKV, and TiFlash nodes according to your performance requirements. For more information, see [Scalability](/tidb-cloud/scalability-concepts.md). +- In a {{{ .starter }}}, {{{ .essential }}}, or {{{ .premium }}} instance, the number and size of TiDB, TiKV, and TiFlash nodes are automatically managed. This ensures seamless scaling, eliminating the need for users to handle node configuration or management tasks. + +### TiDB node + +A [TiDB node](/tidb-computing.md) is a stateless SQL layer that connects to applications using a MySQL-compatible endpoint. It handles tasks like parsing, optimizing, and creating distributed execution plans for SQL queries. + +You can deploy multiple TiDB nodes to scale horizontally and manage higher workloads. These nodes work with load balancers, such as TiProxy or HAProxy, to provide a seamless interface. TiDB nodes do not store data themselves---they forward data requests to TiKV nodes for row-based storage or TiFlash nodes for columnar storage. + +### TiKV node + +A [TiKV node](/tikv-overview.md) is the backbone of data storage in the TiDB architecture, serving as a distributed transactional key-value storage engine that delivers reliability, scalability, and high availability. + +**Key features:** + +- **Region-based data storage** + + - Data is divided into [Regions](https://docs.pingcap.com/tidb/dev/glossary#regionpeerraft-group), each covering a specific Key Range (left-closed, right-open interval: `StartKey` to `EndKey`). + - Multiple Regions coexist within each TiKV node to ensure efficient data distribution. + +- **Transactional support** + + - TiKV nodes provide native distributed transaction support at the key-value level, ensuring Snapshot Isolation as the default isolation level. + - The TiDB node translates SQL execution plans into calls to the TiKV node API, enabling seamless SQL-level transaction support. + +- **High availability** + + - All data in TiKV nodes is replicated (default: three replicas) for durability. + - TiKV ensures native high availability and supports automatic failover, safeguarding against node failures. + +- **Scalability and reliability** + + - TiKV nodes are designed to handle expanding datasets while maintaining distributed consistency and fault tolerance. + +### TiFlash node + +A [TiFlash node](/tiflash/tiflash-overview.md) is a specialized type of storage node within the TiDB architecture. Unlike ordinary TiKV nodes, TiFlash is designed for analytical acceleration with a columnar storage model. + +**Key features:** + +- **Columnar storage** + + TiFlash nodes store data in a columnar format, making them optimized for analytical queries and significantly improving performance for read-intensive workloads. + +- **Vector search index support** + + The vector search index feature uses TiFlash replicas for tables, enabling advanced search capabilities and improving efficiency in complex analytical scenarios. + + + +## Request units and capacity in {{{ .premium }}} {#request-units-and-capacity-in-premium} + +### Request Capacity Unit (RCU) + +A [Request Capacity Unit (RCU)](/tidb-cloud/tidb-cloud-glossary.md#request-capacity-unit-rcu) is a unit of measure used to represent the provisioned compute capacity for your {{{ .premium }}} instance. One RCU provides a fixed amount of compute resources that can process a certain number of RUs per second. The number of RCUs you provision determines the baseline performance and throughput capacity of your {{{ .premium }}} instance. + +One RCU represents a sustained capacity of RUs per second. For example, a baseline of *X* RCUs guarantees *X* RUs per second on average, measured over a one-minute window (or the minimum calculation window configured for your instance). + +### RCU auto-scaling + +When configuring your {{{ .premium }}} instance, you specify the maximum number of RCUs (`RCU_max`) required for your workload. TiDB Cloud automatically scales capacity within the range of `0.25 * RCU_max` to `RCU_max`. + +For example, if you set the maximum capacity to 20,000 RCUs, TiDB Cloud dynamically scales the capacity between 5,000 and 20,000 RCUs based on real-time demand. This scaling is automatic and instantaneous, enabling you to consume up to the maximum number of RCUs at any time without manual intervention or delay. + +### RCU billing + +{{{ .premium }}} uses a usage-based billing model that charges you based on the actual Request Capacity Unit (RCU) consumption and storage usage. + +#### Per-minute calculation + +TiDB Cloud calculates your usage every minute. It measures the total number of Request Units (RUs) consumed within a 60-second window, calculates the average RUs per second, and uses this average value as the RCU consumption for that minute. This calculation ensures that your billing accurately reflects real-time traffic fluctuations. + +#### Minimum usage requirement + +To maintain baseline capacity and ensure that resources are always available for your instance, TiDB Cloud automatically sets a minimum billing RCU based on your maximum RCU setting. This value defines the baseline reserved capacity for your instance. + +If your actual consumption in a given minute is below this threshold, billing defaults to the minimum billing RCU. This mechanism ensures that your instance can immediately handle sudden traffic spikes up to your specified maximum, without performance degradation or delays. + +### Request Unit (RU) + +A [Request Unit (RU)](/tidb-cloud/tidb-cloud-glossary.md#request-unit-ru) is a unit of measure used to represent the resources consumed by a single request to the database. The number of RUs consumed by a request depends on factors such as the operation type and the amount of data retrieved or modified. + +{{{ .premium }}} normalizes the cost of all database operations using Request Units and measures this cost based on throughput (Request Units per second, RU/s). This unified metric makes your throughput costs predictable, helping you manage your application costs more effectively. + +#### Baseline performance examples + +The following table lists baseline performance examples for common operations to help you estimate your workload. + +| Operation type | Description | Estimated cost | +|----------------|------------------------------------------|----------------| +| Point read | Reading a 1 KiB item by its unique ID | 1.5 RU | +| OLTP write | Standard Sysbench model (1 KiB item size) | 2.5 RU | + +> **Note:** +> +> A point read is the most efficient way to retrieve data by its unique ID. For write operations, the RU cost accounts for the I/O and indexing effort required to persist the data. RU consumption scales proportionally with the data size and operation complexity. + +### Request Unit considerations + +TiDB Cloud calculates the total RU charge for any operation based on the database effort required to execute it. The calculation considers the following dimensions: + +- **Data access and size** + + - **Read and write volume**: RUs scale directly with the size of the data payload. Processing a 100 KiB record consumes more RUs than a 1 KiB record. + - **Read and write rows**: the number of rows involved in an operation is a primary cost driver. Even with small payloads, querying or updating multiple rows increases the total RU consumption because each row requires processing, locking, and validation. + - **Indexing impact**: + + - **Writes**: each affected index on a table must be updated during a write operation. Tables with more indexes incur higher RU costs for `INSERT`, `UPDATE`, and `DELETE` operations. + - **Reads**: well-designed indexes significantly reduce query RUs by enabling the engine to locate rows efficiently and avoid full-table scans. + +- **Query complexity** + + - **Scanning efficiency**: RU consumption is heavily influenced by the number of rows that the engine must scan. + + - **Read metrics (estimated rows)**: a point read that uses a primary key or unique index is the most efficient operation. A query that scans millions of rows consumes significantly more RUs than a query that uses an optimized index. + + - **Write metrics (affected rows)**: the RU cost for data modification is tied to the number of affected rows. Modifying 10,000 rows in a single statement results in a much higher charge than modifying a single row. + + - **Computational logic**: complex SQL operations, including multiple table joins, deep subqueries, and aggregations, require more CPU cycles to compute execution paths and process data. + + From 9c17f263f6f6b43f216fb29143e23e097ce1a255 Mon Sep 17 00:00:00 2001 From: qiancai Date: Wed, 26 Aug 2026 09:48:30 +0800 Subject: [PATCH 20/20] fix markdown lint errors --- tidb-cloud/architecture-concepts.md | 1 - tidb-cloud/byoc/create-resource-pool-byoc.md | 10 +++++----- 2 files changed, 5 insertions(+), 6 deletions(-) diff --git a/tidb-cloud/architecture-concepts.md b/tidb-cloud/architecture-concepts.md index 8c90ab295971e..3fddc01c04b90 100644 --- a/tidb-cloud/architecture-concepts.md +++ b/tidb-cloud/architecture-concepts.md @@ -106,7 +106,6 @@ To meet different workload requirements, TiDB Cloud BYOC supports both Single-AZ You can set the high availability mode for each resource pool to **Zonal** or **Regional** when you [create the pool](/tidb-cloud/byoc/create-resource-pool-byoc.md). A zonal resource pool is deployed in a single availability zone, while a regional resource pool is deployed across multiple availability zones. TiDB Cloud determines the availability zone placement based on the BYOC region configuration and available cloud resources. TiDB Cloud BYOC instances created or restored in a resource pool inherit the high availability mode of the pool. After a resource pool is created, you cannot change its high availability mode or availability zone placement. - ![TiDB Cloud BYOC Architecture](/media/tidb-cloud/byoc-architecture.png) A TiDB Cloud BYOC deployment includes the following major components: diff --git a/tidb-cloud/byoc/create-resource-pool-byoc.md b/tidb-cloud/byoc/create-resource-pool-byoc.md index c3a995569cd58..07fceedac2f62 100644 --- a/tidb-cloud/byoc/create-resource-pool-byoc.md +++ b/tidb-cloud/byoc/create-resource-pool-byoc.md @@ -53,11 +53,11 @@ To create a resource pool, take the following steps: - **Zonal**: deploys the resource pool in a single availability zone for lower network latency. - **Regional**: deploys the resource pool across multiple availability zones for higher availability and resilience to outages at the availability zone level. ->**Note:** -> -> - You must select a high availability mode before creating the resource pool. -> - If you select the **Regional** mode, make sure that the region for this pool contains at least three eligible availability zones. If this requirement is not met, the process of creating the regional resource pool might fail to complete. -> - TiDB Cloud determines the availability zones based on the [BYOC region configuration](/tidb-cloud/byoc/byoc-prepare-environment-aws.md#step-3-select-region-and-availability-zones-azs) and available cloud resources. + >**Note:** + > + > - You must select a high availability mode before creating the resource pool. + > - If you select the **Regional** mode, make sure that the region for this pool contains at least three eligible availability zones. If this requirement is not met, the process of creating the regional resource pool might fail to complete. + > - TiDB Cloud determines the availability zones based on the [BYOC region configuration](/tidb-cloud/byoc/byoc-prepare-environment-aws.md#step-3-select-region-and-availability-zones-azs) and available cloud resources. After the resource pool is created, you cannot change its high availability mode or availability zone placement.