If your ApsaraMQ for Kafka instance is using significantly less Internet traffic or fewer partitions than you purchased, you can downgrade these configurations to save costs. This topic describes how to downgrade the Internet traffic, number of partitions, traffic specifications, and disk capacity of an instance in the ApsaraMQ for Kafka console.
Prerequisites
-
The features for downgrading the disk capacity and traffic specifications of an instance are in grayscale release.
-
For stability, we do not recommend significantly downgrading both traffic specifications and disk capacity at the same time.
-
The state of the instance is Running or Not Deployed.
-
For an instance with Internet access enabled, the public bandwidth must be greater than 3 Mbps.
-
No topic traffic rebalance tasks are in progress on the instance.
-
The target number of partitions is greater than the number of partitions in use.
-
The target traffic specifications and disk capacity are at least 1.3 times the current usage.
Precautions
Downgrading an instance configuration may involve restart, throttling, and write prohibition risks. For Serverless instances, there is an additional risk of paused Auto Scaling during the downgrade.
Before you downgrade traffic specifications and disk capacity, review the monitoring data to understand peak usage over a period of time. We recommend reviewing data from the last seven days. Carefully evaluate the target values based on peak usage. An improper assessment can affect the Service-Level Agreement (SLA) for your online services. For more information, see View Cloud Monitor data.
-
Restart risk: Downgrading an instance configuration triggers a rolling restart of the cluster. This may cause the following issues:
-
Clients will briefly disconnect and then reconnect. This may cause a small number of errors.
-
Messages that were sent successfully will not be lost after the downgrade. For messages that fail to send during the downgrade, we recommend retrying the send operation. You can configure a retry mechanism on the client.
-
The downgrade process takes about 30 minutes. The larger the change in disk capacity, the longer it will take. The service will not be interrupted. However, messages in a partition may be consumed out of order. Carefully assess the impact on your business. We recommend downgrading the instance during off-peak hours.
-
-
Throttling risk: If you do not properly assess the target traffic specifications, the following risks may occur:
-
If the target traffic specification is less than 1.3 times the current traffic usage, your instance may be throttled during peak hours.
-
If the target traffic specification is lower than the current traffic usage, your instance will be throttled immediately.
-
For instances with high queries per second (QPS), a downgrade in traffic specifications can cause request congestion. This increases the time for each request, which may exceed the
SESSION_TIMEOUT_MS_CONFIGvalue set on the Kafka client.NoteIn a single downgrade operation, we recommend reducing the traffic specification to no less than 50% of the purchased specification. Monitor your services for stability before you perform another downgrade. For example, if you purchased an alikafka.hw.30xlarge instance and want to downgrade to alikafka.hw.9xlarge, we recommend first downgrading to alikafka.hw.16xlarge. After you confirm that your services are stable, you can then downgrade to alikafka.hw.9xlarge.
-
-
Write prohibition risk: If you do not properly assess the target disk capacity, the following risks may occur:
-
If the target disk capacity is less than 1.3 times the used disk space, a high-traffic instance may quickly run out of space. This can lead to early data deletion and write prohibitions.
-
If the target disk capacity is less than the used disk space, write operations will be prohibited.
-
-
Data risk: When disk usage is high and write traffic remains high, data may be deleted or truncated early to ensure stability.
-
Stability risk: Because cloud disks do not natively support capacity downgrades, ApsaraMQ for Kafka uses additional cluster CPU and disk I/O to perform this operation. For instances with high resource usage, downgrading disk capacity can create stability risks. Before you downgrade the disk capacity, identify and resolve any existing instance risks to ensure the instance is in a healthy state.
-
Paused Auto Scaling risk: During an upgrade or downgrade of a Serverless instance, Auto Scaling is paused. Make sure to perform this operation when your business usage is stable.
Scenarios and risks
|
Scenario |
Risk |
|
The traffic usage of a non-Serverless ApsaraMQ for Kafka instance is consistently lower than the purchased traffic specification. In this case, you can downgrade the instance's traffic specification. |
|
|
The disk usage of a non-Serverless ApsaraMQ for Kafka instance is consistently low. In this case, you can reduce the disk capacity. |
Write operations to your current services may be prohibited. For more information, see the write prohibition risk information in the Precautions section. |
|
Changing the number of partitions or topics for a non-Serverless ApsaraMQ for Kafka instance. The number of partitions or topics after the downgrade is not less than the number in actual use. Note
For newly purchased instances, you can only change the number of partitions. For instances purchased before August 26, 2022, you can also change the number of topics. |
None. |
|
Downgrading the public bandwidth of a non-Serverless ApsaraMQ for Kafka instance. |
None. |
|
Downgrading the base usage billing specification for a Serverless ApsaraMQ for Kafka instance. |
Auto Scaling is paused after the downgrade. |
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.
-
On the Instance Details page, in the upper-right corner of the Overview section, click Downgrade.
-
In the downgrade panel, set Public Traffic, Partition Specification, Traffic Specification, and Disk Capacity, read and accept the service agreement, and then click Buy Now.
Important-
To prevent network throttling from insufficient bandwidth, ApsaraMQ for Kafka estimates the optimal bandwidth based on your selected instance type. Purchase Internet traffic in multiples as prompted on the page.
-
The number of partitions after the downgrade cannot be less than the number of partitions currently in use.
-
When the current resource usage of the cluster, such as CPU, is high, the downgrade page restricts downgrades of traffic specifications to ensure stability.
-
For Professional Edition (High-write) and Professional Edition (High-read) instances, only instances with traffic specifications lower than alikafka.hw.60xlarge or alikafka.hr.60xlarge can be downgraded. The feature to downgrade traffic specifications for instances of alikafka.hw.60xlarge, alikafka.hr.60xlarge, or higher is in grayscale release. To use this feature, submit a ticket.
-
When you downgrade an instance configuration without changing the disk capacity, the time required for the downgrade depends on the instance size. For instances of alikafka.hr.30xlarge, alikafka.hw.30xlarge, or lower, the process takes about 30 minutes. For instances of alikafka.hr.60xlarge, alikafka.hw.60xlarge, or higher, the process takes more than one hour. In general, the larger the instance and the more topics it has, the longer the process takes. If the downgrade involves reducing disk capacity, the process takes longer because historical data must be copied. The time required is proportional to the amount of data on the disk.
On the Instance Details page, in the Basic Information section, the instance Status changes to Upgrading. The new specifications are displayed after the downgrade is complete.
-