You can migrate a TencentDB for MySQL instance to another AZ in the same region. All its attributes, configurations, and connection address will stay unchanged after the migration. The time it takes to migrate the instance is subject to the instance's data volume.
For example, you can migrate to a new AZ in the following scenarios:
If you want to modify an instance's type, but the current AZ doesn't support the new instance type, you can migrate the instance to an AZ supporting the new type.
If the current AZ has no remaining resources for scaling, you can also migrate the instance to another AZ in the same region with sufficient resources to meet your business needs.
Prerequisites
The instance is running and uses the two-node or three-node architecture.
The region where the instance is located has multiple AZs to support cross-AZ migration.
Billing description
This feature is free of charge. There is no charge even for migrating an instance from a single AZ to multiple AZs.
Feature overview
AZ migration will not result in a VIP change.
The source instance is not decoupled from the read-only instances after AZ migration and can still be synced with them.
You can choose the AZ of read-only instances.
If the target instance has a task lock on the cloud platform during the DTS task, cross-AZ migration cannot be performed.
If there are ongoing DTS tasks, after AZ migration, you need to restart such tasks.
DTS export will fail if the source instance undergoes a cross-AZ migration switch during dumper export.
Impact
The instance will be momentarily affected when its AZ is switched; therefore, make sure that your application has an automatic reconnection mechanism.
Use limits
During the migration of the availability zone, the system will check if the instance disk is overused. If the disk is overused, the migration of the availability zone cannot be carried out. It is recommended to retry after expanding the disk. If the disk space has exceeded the maximum storage limit of the current instance specification, it is recommended to retry after upgrading the instance specification configuration. For detailed specifications, disk limits, and related operations, please refer to Adjusting Database Instance Specifications.
RO instances do not support cross-regional migration.
The migration of the availability zone does not currently support enabling instances with the database proxy. Please turn off the database proxy before migrating across availability zones.
During the migration switch, access via the RO group is not possible (excluded).
Under the dual-node and triple-node architecture, the selection of the primary and secondary availability zones for migration is subject to regional and remaining resource restrictions. When migrating in the console, select the target availability zone, and the secondary availability zone option will automatically update.
RO instances in the same availability zone as the primary instance will by default migrate to the target availability zone with the primary instance. RO instances not in the same availability zone as the primary instance do not currently support the migration of availability zone operations.
Migration type
Migration Type
Applicable Scenario
Supported Instance Types
Migration from one AZ to another AZ
The AZ where the instance is located is under full load or other conditions that affect the instance performance.
Source, read-only, and disaster recovery instances
Migration from one AZ to multiple AZs
You can improve the disaster recovery capability of the instance and implement cross-data center disaster recovery. Source and replica instances are located in different AZs. Multi-AZ instances can withstand higher levels of disasters than single-AZ instances. For example, the latter can tolerate server- and rack-level failures, while the former can tolerate data center-level failures.
Source, read-only, and disaster recovery instances
Migration from multiple AZs to one AZ
You want to meet specific feature requirements.
Source, read-only, and disaster recovery instances
Directions
1. Log in to the TencentDB for MySQL console. In the instance list, click an instance ID or Manage in the Operation column to enter the instance details page.
2. On the Instance Details page, select Basic Info > Region/AZ and click Migrate to New AZ, or select Availability Info > Deployment Mode and click Modify Replica AZ.
3. In the pop-up window, adjust the relevant configurations and click Submit after confirming that everything is correct.
New AZ: You can change the source AZ in the drop-down list or select Yes for Multi-AZ Deployment to modify the replica AZ.
Delay Threshold for Data Consistency Check: This option is available only when you change the primary AZ. The threshold can be an integer between 1 and 10 seconds.
Note:
There may be a delay during the data consistency check. You need to set a data delay threshold. The database consistency check will be paused when the delay exceeds the set value and will be resumed when the delay drops below the threshold. If the threshold value is too small, the migration may take longer.
Switch Time: You can choose to switch during the maintenance time or upon migration completion. For more information, see Setting Instance Maintenance Time.
Same Availability Zone RO Instance Migration: (This setting only appears when the primary instance has a read-only instance in the same availability zone.) Select whether the same availability zone RO should follow the primary instance to migrate to the new availability zone.
Note：
During the process of adjusting configurations, data migration may occur within the instance. However, this will not affect the accessibility of the instance. After the migration is complete, a switch will occur, resulting in a second-level disconnection. Please ensure that your operations possess a reconnection mechanism.
Yes
No
Was this page helpful?