TDMQ for CKafka
- Release Notes and Announcements
- Product Introduction
- Technical Principles
- High Availability
- Purchase Guide
- Billing Overview
- Getting Started
- Obtaining Access Permission
- VPC Access
- Step 4. Send/Receive Messages
- Access via Public Domain Name
- Step 5. Send/Receive Messages
- Development Guide
- Operation Guide
- Instance Management
- Topic Management
- Instance Topic
- Elastic Topic
- Consumer Group
- Monitoring and Alarms
- Smart Ops
- Permission Management
- Migration to Cloud
- CKafka Connector
- Task Management
- Creating Data Access Task
- Creating Data Distribution Task
- Simple Data Processing
- Practical Tutorial
- Practical Tutorial of CKafka Client
- Connector Practical Tutorial
- Reporting over HTTP
- Querying Subscription to Database Change Info
- Log Access
- Troubleshooting
- Topic Failures
- Consumer Group Failures
- Client Failures
- API Documentation
- Making API Requests
- DataHub APIs
- ACL APIs
- Topic APIs
- Instance APIs
- Other APIs
- SDK Documentation
- SDK for Java
- SDK for Python
- SDK for Node.js
- SDK for Connector
- Elastic Topic Message Sending and Receiving
- General References
- Connector
- Database Change Subscription
- FAQs
Migrating Availability Zones
Last updated: 2025-04-09 10:13:32
Overview
You can migrate Pro Edition instances of TDMQ for CKafka to other AZs within the same region. After migrating availability zones, all attributes, configurations, and connection addresses of the instance will not change. The time required for migration depends on the data volume of the instance.
For example, in following scenarios, you can choose to migrate availability zones:
Assume you are attempting to modify the instance type of an instance, but we are unable to start an instance of the new instance type in the current availability zone. In such cases, you can migrate the instance to an availability zone where that instance type can be started.
If there are no resources available for capacity expansion in the current availability zone, you can also migrate the instance to another availability zone with sufficient resources in the same region to meet business needs.
Prerequisites
The instance is running.
The region where the instance is located needs to have multiple availability zones to support the migrating availability zones functionality.
Fee Description
This feature is free. Even if you migrate an instance from a single availability zone to multiple availability zones, it is not billed.
Feature Description
When the original instance is in single-AZ deployment, you can switch the availability zone or upgrade to multi-AZ deployment. For details about multi-AZ deployment, see Cross-AZ Deployment.
When the original instance is in multi-AZ deployment, you can switch the availability zone, but cannot switch back to single-AZ deployment.
Migration Types and Scenario Notes
Migration Type | Scenario |
Migrating from one availability zone to another availability zone | The Instance Availability Zone experiences full load or other circumstances that affect instance performance. |
Migrating from one availability zone to multiple availability zones | Improve the disaster recovery capability of the instance and achieve cross-IDC disaster recovery. Primary/secondary instances are located respectively in different AZs. Compared with single-AZ instances, multi-AZ instances can withstand higher-level disasters. For example, single-AZ instances can withstand server and rack-level failures, while multi-AZ instances can withstand IDC-level failures. |
Operation Steps
Note:
During the process of modifying the availability zone, there may be a leader switch. The client needs a retry policy for fault tolerance; otherwise, it may lead to disconnection. A business restart is required for reconnection.
1. Log in to CKafka console.
2. Click Instance List in the left sidebar. Click the ID/Name of the target instance to access the basic information page.
3. In the basic information module, click the Edit Button on the right of the availability zone and select the availability zone you want to switch to.
4.Click "Confirm", and it is estimated to take 5-10 minutes to complete the configuration change. You can check the progress of the configuration change in the status column of the instance list.
Was this page helpful?
You can also Contact Sales or Submit a Ticket for help.
Yes
No