How to downgrade instance configurations in the console - ApsaraMQ for Kafka

If your ApsaraMQ for Kafka instance uses less Internet traffic or partitions than the Internet traffic or partitions that you purchased, you can downgrade the corresponding configurations to reduce costs. This topic describes how to downgrade the Internet traffic, partition number, traffic specification, and disk capacity of an instance in the ApsaraMQ for Kafka console.

Prerequisites

Important

The disk capacity downgrade feature and the traffic specification downgrade feature are available only in canary releases.
For system stability, you cannot downgrade the traffic specification and disk capacity of an ApsaraMQ for Kafka instance at the same time if the decreases are large.

The instance is in the Running or Not Deployed state.
The Internet traffic of an ApsaraMQ for Kafka instance for which Internet access is enabled must be greater than the minimum bandwidth 3 Mbit/s.
No ongoing traffic rebalancing tasks exist in the instance.
The number of partitions that you want to specify is greater than the number of partitions in use.
The traffic specification and disk capacity that you want to specify are at least 1.3 times the traffic specification and disk capacity in use.

Usage notes

If you downgrade the configurations of an ApsaraMQ for Kafka instance, risks, such as broker restart, traffic throttling, and write prohibition, may occur. If you downgrade the configurations of a serverless ApsaraMQ for Kafka instance, auto scaling activities in the instance are suspended.

Warning

Before you downgrade the traffic specification and disk capacity of an ApsaraMQ for Kafka instance, you must check the peak values of resource usage in the instance in a specific period of time, such as the past seven days, and then specify new traffic specification and disk capacity accordingly. If your new configurations are lower than your actual business usage, the service level agreement (SLA) of your online business is affected after the downgrade. Proceed with caution when you downgrade instance configurations. For more information, see View monitoring data.

Broker restart: After you downgrade the configurations of an instance, brokers in the cluster restart one by one, which may cause the following risks:
- Clients are temporarily disconnected and reconnected, and a few errors may be reported.
- Messages may fail to be sent during a downgrade. In this case, we recommend that you configure the message retry feature on the client to resend the messages. Messages that have been sent are not lost after a downgrade.
- A long time is consumed for downgrades. In most cases, a downgrade requires approximately 30 minutes to complete. The larger the decrease in disk capacity is, the longer time the downgrade takes. The downgrade does not interrupt services but messages may be distributed to a different partition for consumption. We recommend that you assess the impact on your business and downgrade instance configurations during off-peak hours.
Traffic throttling: If your traffic specification after a downgrade is lower than your actual business usage, the following risks may occur:
- If the traffic specification that you specify is less than 1.3 times the actual business traffic, throttling may be triggered on your instance during peak hours.
- If the traffic specification that you specify is lower than the actual business traffic, throttling is immediately triggered on your instance.
- If you downgrade the traffic specification of an instance that has high queries per second (QPS), requests are concentrated on a specific node. In this case, the time consumed to handle a request increases or may exceed the value specified for the SESSION_TIMEOUT_MS_CONFIG parameter on the client.
  Note
  We recommend that you downgrade the traffic specification by 50% at most. If a further downgrade is necessary, perform the downgrade after your business stabilizes. For example, if you purchased an instance with the alikafka.hw.30xlarge traffic specification and want to downgrade the specification to alikafka.hw.9xlarge, we recommend that you downgrade the specification to alikafka.hw.16xlarge and then to alikafka.hw.9xlarge after your business stabilizes.
Write prohibition: If your disk capacity after downgrade is lower than your actual business usage, the following risks may occur:
- If the disk capacity that you specify for an instance with high traffic is less than 1.3 times the disk capacity in use, the disk of the instance soon becomes full. As a result, data is deleted ahead of schedule and write prohibition is triggered.
- If the disk capacity that you specify is less than the disk capacity in use, write prohibition is immediately triggered.
Data risks: If the disk usage and write traffic are high, data may be deleted ahead of schedule or truncated to ensure system stability.
System instability: Disks do not support capacity downgrading. To downgrade the disk capacity of an ApsaraMQ for Kafka instance, extra cluster CPU and disk I/O are consumed. If you downgrade the disk capacity of an ApsaraMQ for Kafka instance when the resource usage is high, the system may become unstable. We recommend that you check whether unhandled risks exist in the instance before you downgrade the disk capacity. If unhandled risks exist, handle the risks before you downgrade the disk capacity.
Suspension of auto scaling activities: During the configuration upgrade or downgrade of a serverless ApsaraMQ for Kafka instance, auto scaling activities in the instance are suspended. Make sure that you upgrade or downgrade the configurations of a serverless ApsaraMQ for Kafka instance when your business traffic is stable.

Scenarios and risks

Scenario	Risk
The traffic specification of your non-serverless ApsaraMQ for Kafka instance needs to be downgraded because your actual business usage is lower than the traffic specification that you purchased at all times.	Your traffic may be throttled. For more information, see the traffic throttling risk described in the "Usage notes" section of this topic.
The disk capacity of your non-serverless ApsaraMQ for Kafka instance needs to be downgraded because your actual business usage is lower than the disk capacity that you purchased.	Data writes may be prohibited. For more information, see the write prohibition risk described in the "Usage notes" section of this topic.
The partition or topic number of your non-serverless ApsaraMQ for Kafka instance needs to be changed. The number of partitions or topics after a downgrade must be greater than or equal to the number of partitions or topics in use. Note You can change only the number of partitions for instances purchased on and after August 26, 2022, and only the number of topics for instances purchased before August 26, 2022.	None.
The Internet bandwidth of your non-serverless ApsaraMQ for Kafka instance needs to be changed.	None.
The minimum usage specification of your ApsaraMQ for Kafka serverless instance needs to be downgraded.	After the downgrade, auto scaling activities in the instance are suspended.

Procedure

Log on to the ApsaraMQ for Kafka console.
In the Resource Distribution section of the Overview page, select the region where the ApsaraMQ for Kafka instance that you want to manage resides.
On the Instances page, click the name of the instance that you want to manage.
In the upper-right corner of the Instance Details page, click Downgrade in the Overview section.
In the instance downgrade panel, configure the Public Traffic, Partitions, Traffic Specification, and Disk Capacity parameters, read and agree to the terms of service, and then click Buy Now.
Important
- To prevent traffic throttling caused by insufficient bandwidth, ApsaraMQ for Kafka estimates the optimal bandwidth based on the instance type that you selected. You can follow the on-screen instructions on the buy page to purchase the Internet traffic specification that meets your business requirements.
- The number of partitions after a downgrade must be greater than or equal to the number of partitions in use.
- If the resource usage, such as the CPU usage, of your cluster is high, a limit is imposed when you downgrade the traffic specification on the downgrade page.
- For Professional Edition (High Write) instances, you can downgrade only traffic specifications that are lower than alikafka.hw.60xlarge. For Professional Edition (High Read) instances, you can downgrade only traffic specifications that are lower than alikafka.hr.60xlarge.
- If the disks of an ApsaraMQ for Kafka instance are not to be downgraded, the time that is required to downgrade the instance is determined by the instance specification. For example, for instances that use the alikafka.hr.30xlarge specification or lower or the alikafka.hw.30xlarge specification or lower, the downgrade requires approximately 30 minutes to complete. For instances that use the alikafka.hr.60xlarge specification or higher or the alikafka.hw.60xlarge specification or higher, the downgrade requires approximately 1 hour to complete. In most cases, the downgrade time linearly increases with the instance specification. If the disks of an ApsaraMQ for Kafka instance are to be downgraded, the time that is required to downgrade the instance can be longer because historical data needs to be copied. The downgrade time is positively correlated with the number of disks.
In the Basic Information section of the Instance Details page, the status of the instance changes to Upgrading. After the downgrade is complete, the new configurations are displayed in the Basic Information section.