Instance-Related
마지막 업데이트 시간:2025-09-28 16:17:41
Instance Upgrade Modes and Key Differences
When the system algorithm detects that the current dedicated resource pool has insufficient quota for the upgraded configuration, it must automatically add resources to the resource pool and migrate the instance data. Therefore, there are two upgrade modes:
When resources are sufficient, the instant upgrade mode increases quota and completes within minutes.
When resources are insufficient, the data migration mode depends on the accumulated data size in the cluster and may take a few minutes to hours.
When data migration is required, the migration time can be customized.
When data migration is required, there will be two options: migration mode and scheduled migration. The migration mode is divided into two types as follows:
Stable mode: CKafka limits the data migration speed during the upgrade process to maximize the bandwidth of an instance, suitable for scenarios where business interference is not desired.
High-speed mode: CKafka does not limit the data migration speed during the upgrade process, which may affect the production and consumption bandwidth of the instance. It is suitable for off-peak hours or scenarios where service interruption is allowed.
Because migration may occupy cluster bandwidth and disk resources, customers may worry about migration affecting business during peak hours. Therefore, scheduled migration can be configured, such as setting it to perform upgrades at midnight. For details, see Changing Instance Specifications.
Why Is Traffic Throttling Triggered When Cluster Bandwidth Percentage Is below 100%
From the monitoring interface, you can see that the production or consumption bandwidth percentage of the cluster instance does not exceed 100%, but the maximum production or consumption bandwidth of the instance has already exceeded the purchased cluster bandwidth. Meanwhile, the cluster throttling count is not 0. This symptom occurs for the following two reasons:
1. The current cluster uses a throttling mechanism that adopts a soft delayed packet response for high-volume scenarios like Kafka. In extreme cases, the maximum production/consumption bandwidth of an instance may exceed the purchased cluster bandwidth. For details, refer to Throttling Mechanism Description.
2. The bandwidth percentage metric uses a peak-shaving and valley-filling way to present the current cluster utilization ratio. Our calculation method obtains the average per unit time, which leads to the above problem.
Maximum Production/Consumption Bandwidth Exceeds Purchased Cluster Bandwidth but No Throttling Occurs
The current cluster's throttling mechanism employs a relatively soft delayed packet response for high-volume scenarios like Kafka. In extreme cases, the instance's maximum production/consumption bandwidth may exceed the purchased cluster bandwidth. For details, please refer to Throttling Mechanism Description.
Does the Instance Support Data Compression
Currently CKafka supports open source snappy and lz4 message compression formats. Gzip compression is not yet supported due to its high CPU consumption. Enabling compression may increase server pressure in some cases, such as when the producer version is high and the consumer protocol edition is low, leading to protocol conversion during consumption. This can cause higher server pressure. So if necessary for testing, it is recommended that customers turn off message compression parameters for testing.
Method to enable configuration: Set compression.type = snappy or lz4 in the Producer configuration file. The default setting is none.
It is recommended to select Snappy compression first. After enabling compression, it may lead to an increase in server CPU and higher production and consumption duration. Use with caution.
피드백