A single-zone ApsaraMQ for Kafka instance is vulnerable to zone-level failures. By adding a secondary zone, you distribute brokers across two availability zones so the cluster continues to serve read and write requests when one zone becomes unavailable.
The zone upgrade feature is in canary release. To enable it, submit a ticket.
How multi-zone deployment works
When you upgrade a single-zone instance, ApsaraMQ for Kafka:
Provisions new brokers in the secondary zone.
Redistributes existing brokers so that both zones serve traffic.
Rebalances topic partition replicas across brokers in both zones to ensure data redundancy.
After the upgrade, if one zone becomes unavailable, the brokers in the other zone continue to handle producer and consumer requests.
Prerequisites
Before you begin, make sure that you have:
An ApsaraMQ for Kafka Professional Edition instance
A single-zone deployment (the instance has not yet been upgraded to multi-zone)
Read and write traffic usage well below the instance specification limit
Major version 2.2.0 or later (recommended: the latest minor version)
Automatic reconnection and retry logic configured for all Kafka producers and consumers
Service impact
The upgrade does not interrupt the service but may cause temporary service unavailability:
Broker restarts: Some cluster nodes restart during the upgrade, which temporarily reduces cluster capacity.
Client disconnections: Producers and consumers may disconnect when a broker restarts. Without automatic reconnection logic, clients may not be able to reconnect to the broker after disconnection.
Schedule the upgrade during a maintenance window with low traffic.
Estimated duration
The total upgrade time consists of the zone upgrade time (broker provisioning and redistribution) and the topic traffic rebalance time.
Zone upgrade time
| Instance specification | Estimated time |
|---|---|
alikafka.hr.30xlarge or lower / alikafka.hw.30xlarge or lower | ~20 minutes |
alikafka.hr.60xlarge or higher / alikafka.hw.60xlarge or higher | 40+ minutes |
The upgrade time scales linearly with the instance specification.
Topic traffic rebalance time
| Storage type | Estimated time | Notes |
|---|---|---|
| Cloud storage | ~30 seconds per topic | Minimal impact |
| Local storage | Minutes to hours | Depends on the volume of data to migrate. Large datasets may take hours. Schedule during off-peak hours. |
Upgrade a single-zone instance to multi-zone
Log on to the ApsaraMQ for Kafka console.
In the Resource Distribution section of the Overview page, select the region where your instance resides.
On the Instances page, click the name of the instance that you want to upgrade.
In the Configuration Information section of the Instance Details page, click Edit next to Secondary Zone.
In the panel that appears, configure the following parameters:
Parameter Description Secondary Zone The availability zone to add as the secondary zone Start At When to start the upgrade In the Notes on Zone Upgrade dialog box, review the risks and click OK.
Verify the upgrade
After the upgrade completes, return to the Instance Details page and confirm that the Secondary Zone field displays the zone you selected.
Best practices
Before the upgrade
Check traffic headroom. Verify that your instance is not approaching its specification limit for read and write traffic. Broker restarts during the upgrade temporarily reduce cluster capacity.
Configure client reconnection. Enable automatic reconnection and retry logic for all Kafka producers and consumers.
Upgrade to the latest minor version. Update your instance to the latest minor version before you start, to benefit from stability improvements.
During the upgrade
Monitor the cluster. Watch broker health and partition status in the ApsaraMQ for Kafka console throughout the upgrade.