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 status is Running, and the instances are of the two-node, three-node, or Cluster Edition 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.
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.
If an instance is in an automatic backup cycle when cross-AZ migration is completed, the system generates an additional backup. For example, an automatic backup operation on August 5 is scheduled for an instance, but the instance is undergoing cross-AZ migration on that day. In this case, the system triggers another backup operation when migration is completed, in addition to the scheduled automatic backup operation.
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. Instances of single-node (cloud disk) architecture and two-node economical architecture and read-only analysis engines cannot be migrated across availability zones (AZs). Read-only instances in a different AZ from the primary instance cannot be migrated to other AZs. However, read-only instances in the same AZ as the primary instance can be migrated to the AZ to which the primary instance is migrated.
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).
For migration to other AZs, the selection of primary and secondary AZs is limited to a specific region and the remaining resources in the region.
Migration type
|
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. | Primary instance and disaster recovery instance |
Migration from multiple AZs to one AZ | You want to meet specific feature requirements. | Primary instance and disaster recovery instance |
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. Choose Instance Details > Instance Info, and click Migrate next to Deployment Mode.
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.
Intra-AZ 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:
Data migration may occur in the process of instance configuration adjustment, during which instance access is not affected. After the completion of migration, the switch will be performed based on the selected switch time, which may cause a second-level momentary disconnection. Ensure that your business has a reconnection mechanism.