When you upgrade ApsaraMQ for Kafka brokers, you might experience message ordering issues, client disconnections, or uneven message distribution across partitions.
When you upgrade ApsaraMQ for Kafka brokers, the following issues may occur:
During the upgrade, all brokers in the ApsaraMQ for Kafka cluster restart one by one. Services continue without interruption during broker restarts. However, messages consumed within 5 minutes after each broker restart may be out of order in specific partitions. Note that serverless ApsaraMQ for Kafka and ApsaraMQ for Confluent instances fully comply with Apache Kafka semantics during version upgrades.
During broker restarts, clients connected to those brokers may experience disconnections. If clients support automatic reconnection, other brokers will automatically take over the services.
During broker upgrades and restarts, message processing volumes may become uneven across different partitions. You should evaluate how this might impact your business operations.
Broker IP addresses might change in some scenarios. Ensure your clients connect to the Kafka server using domain names rather than IP addresses.
The upgrade process for all brokers typically takes between 5 and 15 minutes. If you manage multiple instances, you can upgrade a test cluster first. After verifying the upgrade results on the test cluster, you can proceed with upgrading your production cluster.
If you use a Go client developed with the Sarama library to send and subscribe to messages, you might experience message duplication during broker upgrades. For more information, see Why is it not recommended to use a Sarama Go client to send or receive messages?.