You can adjust the deployment AZs within the same region where your TDSQL Boundless instance resides. After the AZs are adjusted, all attributes, configurations, and connection addresses of the instance remain unchanged. The time required for the AZ adjustment depends on the data volume of the instance.
For example, you can choose to adjust the deployment AZs of your instance in the following scenarios:
If you need to enhance the cross-AZ disaster recovery capability of your instance, you can adjust its deployment from a single AZ to multiple AZs.
If you prioritize ultimate performance and want to reduce network latency introduced by cross-AZ access, you can adjust your instance deployment from multiple AZs to a single AZ.
If you need to adjust the source AZ of your instance due to application deployment planning to reduce cross-AZ access latency, you can do so.
If the current AZ lacks resources for scaling out, you can also adjust your instance deployment from a single AZ to a multi-AZ deployment with sufficient resources within the same region to meet business requirements.
Prerequisites
Note:
A dual-replica instance (with 2 full-feature replicas + 1 log replica) only supports changing the source AZ. It does not support adjusting the AZ combination (including changing the number of AZs).
The instance status is running, and the instance is a Cluster Edition instance with three replicas.
The region where the instance resides must have multiple AZs to support the AZ migration feature.
The kernel version of the instance must meet the requirements specified in the following table:
|
Multi-AZ to single-AZ. | V17.0.0 | Downgrading from three-AZ to single-AZ. |
Single-AZ to multi-AZ. | V18.2.0 | Upgrading from single-AZ to three-AZ. |
Upgrading to a target AZ that does not include the original AZ. | V18.1.0 | Applicable only to three-replica instances, for example, upgrading from "AZ1 only" to "AZ2 + AZ3 + AZ4". |
Changing the source AZ (for existing multi-AZ instances). | V19.0.0 | Switching the source AZ within the existing AZ combination. |
Fee Instructions
This feature is free of charge. Even if you migrate an instance from a single AZ to multiple AZs, no fees are charged.
Usage Impact
During the adjustment of the instance's AZ, the instance remains readable and writable. However, brief performance fluctuations and second-level connection interruptions may occur. Ensure that your application has an automatic reconnection mechanism.
Adjusting the AZ of an instance involves cross-AZ data synchronization or replica rebuilding. The duration of the adjustment is related to the data volume and the number of nodes. We recommend performing this operation during off-peak business hours. This process does not cause data loss. However, for critical business, we recommend backing up data in advance to enable quick recovery in case of exceptions.
When you change the source AZ, second-level connection interruptions may occur. Ensure that your application has an automatic reconnection mechanism.
Use Limits
The supported AZ adjustment operations differ based on the number of full-feature replicas. For details, see the following table:
|
Three-Replica Instance | Single-AZ | Two AZs | Not applicable |
| Single-AZ | Three AZs | Supported Note: The number of peer nodes in an instance must be a positive integer multiple of 3, such as 3, 6, 9, and so on. When the kernel version is earlier than V18.1.0, the target AZ combination must include the original AZ. When the kernel version is V18.1.0 or later, you can upgrade to a target AZ that does not include the original AZ. |
| Three AZs | Single-AZ | Supported Note: When the kernel version is earlier than V18.1.0, the target AZ combination must include the original AZ. When the kernel version is V18.1.0 or later, you can upgrade to a target AZ that does not include the original AZ. Warning: After you switch to a single-AZ deployment, all replicas of the instance are concentrated in the same AZ. If an AZ failure occurs, service unavailability will result. |
| Multiple availability zones (AZs) | Changing the source AZ | Supported Note: The kernel version must be V19.0.0 or later. |
Two-Replica Instance | Single-AZ | Two AZs | Not supported. Two-replica instances do not support adjusting AZ distribution. |
| Two AZs | Single-AZ | Not supported. Two-replica instances do not support adjusting AZ distribution. |
| Multiple AZs | Changing the source AZ | Supported. Two-replica instances only support changing the source AZ. Note: The kernel version must be V19.0.0 or later. |
During the deployment mode adjustment, other configuration change operations, such as specification changes and node number adjustments, cannot be performed simultaneously.
When you adjust AZs, the selection of deployment AZs for the instance is restricted by the remaining resources in the region and zones.
Steps
Upgrading from a Single-AZ to Three AZs
Applicable Objects: Instances deployed with three replicas in a single AZ.
1. Log in to the TDSQL Boundless console. In the Instance List, locate the target instance and click its Instance ID to go to the Instance Details page. 2. On the Instance Details page, click More > Migrate AZ in the upper-right corner to go to the Change Deployment Mode page.
3. On the Change Deployment Mode page, configure the following parameters.
|
Target Deployment Mode | Select Three AZs. |
AZ | Select three AZs. When the kernel version is not lower than V18.1.0, the target AZs may not include the original AZ. For example, upgrade a single-AZ instance originally deployed in "Guangzhou Zone 1" to a three-AZ deployment in "Guangzhou Zone 2 + Guangzhou Zone 3 + Guangzhou Zone 4". |
Source AZ | Select one AZ from the three selected AZs as the source AZ to handle read and write traffic. |
Number of hybrid nodes after adjustment | Must be a positive integer multiple of 3, such as 3, 6, 9, and so on. |
4. Confirm the adjusted configuration and billing information, and then click Change Deployment Mode.
Downgrading from a Three AZs to a Single-AZ Deployment
Note:
After you downgrade to a single AZ, all replicas will be concentrated in the same AZ. If that AZ fails, service unavailability will result. Before downgrading, evaluate your business availability requirements.
1. Log in to the TDSQL Boundless console. In the Instance List, locate the target instance and click its Instance ID to go to the Instance Details page. 2. On the Instance Details page, click More > Migrate AZ in the upper-right corner to go to the Change Deployment Mode page.
3. Configuration Parameters:
Target Deployment Mode: Select Single-AZ.
AZ: Select one target AZ.
4. After the configuration and billing information are confirmed, click Change Deployment Mode.
Changing the Source AZ
Note:
When you change the source AZ, second-level connection interruptions may occur. Ensure that your business side has a reconnection capability.
For a multi-AZ instance, you can set a source AZ. After you set it, the node weight in that AZ is increased to 99%, and approximately 99% of requests are prioritized for processing in that AZ.
After you set a source AZ, the instance configuration cannot be adjusted. If you need to change the configuration, temporarily cancel the source AZ configuration first. This allows TDSQL Boundless to switch the Leader as needed during the configuration change to ensure business continuity. Before performing this operation, evaluate the potential performance impact of canceling the source AZ.
1. Log in to the TDSQL Boundless console. In the Instance List, locate the target instance and click its Instance ID to go to the Instance Details page. 2. On the Instance Details page, click More > Migrate AZ in the upper-right corner to go to the Change Deployment Mode page.
3. Configuration Parameters:
Target Deployment Mode: Keep it consistent with the original deployment mode.
Source AZ: Select a new source AZ from the original AZ combination.
4. After confirming the configuration, click Change Deployment Mode.
FAQs
Why Can't My Dual-Replica Instance Be Adjusted to Three AZs?
The replica configuration of a dual-replica instance (with 2 full-feature replicas + 1 log replica) determines that it can only be deployed across 2 AZs.
Why is the 'Target Deployment Mode' option grayed out on the 'Change Deployment Mode' page?
Possible causes:
The instance replica configuration does not match the target deployment mode (for example, a three-replica instance cannot be adjusted to a dual-AZ deployment).
The number of peer nodes in the instance does not meet the multiple requirement of the target deployment mode.
The kernel version of the instance is lower than the minimum requirement of the target deployment mode.
How long does it take to change the deployment mode?
The adjustment duration is related to the instance data volume and the number of nodes. Upgrading from a single AZ to three AZs involves cross-AZ data synchronization, which takes a long time. Changing only the source AZ involves only route switching and is typically completed within minutes.
Will the service be impacted during the adjustment process?
Replica Rebuild Adjustments (such as scaling up/down AZs): The workload remains continuously readable and writable, but performance fluctuations may occur.
Source AZ Change: This triggers a primary/secondary switchover. Second-level connection interruptions may occur on the business side, which must have a reconnection capability.
If the adjustment fails, will it roll back?
If the adjustment task fails, the system automatically rolls back to the pre-adjustment state. If the adjustment fails multiple times, contact Tencent Cloud Technical Support.
Can I perform other configuration changes during the adjustment?
No. During the deployment mode adjustment is being performed, the instance is in a configuration change mutual exclusion state and does not support performing other configuration change operations, such as specification changes, simultaneously. Wait until the current adjustment task is completed before initiating other configuration change operations.
Does cross-AZ data synchronization affect instance performance?
When adjustment to multiple AZs is performed or the AZ combination is changed, cross-AZ data synchronization or replica rebuilding is involved, which may cause the following impacts:
Write Latency: In a multi-AZ deployment, writes need to be replicated across AZs, resulting in slightly higher latency compared to a single-AZ deployment.
Performance Fluctuations During Synchronization: During the adjustment, the instance remains readable and writable. However, data synchronization consumes some network and I/O resources, which may cause brief performance fluctuations.
Recommendation: Perform the adjustment during off-peak business hours and evaluate the workload's tolerance for latency in advance.