Instances
What Are the Instance Upgrade Modes? What Are their Main Differences?
When the system algorithm detects that the current dedicated resource pool has insufficient quotas for the upgraded configuration, it needs to 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 quotas and completes within minutes.
When resources are insufficient, the data migration mode depends on the size of data accumulated in the cluster and may take from a few minutes to several hours.
When data migration is required, the migration time can be customized:
When data migration is required, there are two options: migration mode and scheduled migration. The migration mode is divided into the following two types:
Stable mode: TDMQ for CKafka limits the data migration speed during the upgrade process to maximize the bandwidth of an instance. This mode is 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. This mode 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 how to upgrade configurations, see Changing Instance Specifications.
Why Is Traffic Throttling Triggered When the Cluster Bandwidth Percentage Is Below 100%?
From the monitoring page, 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 number of traffic throttling events for the cluster is not 0. This symptom occurs for the following two reasons:
1. The current cluster uses a traffic throttling mechanism that adopts a relatively soft delayed packet response for high-volume scenarios such as Kafka. In extreme cases, the maximum production/consumption bandwidth of an instance may exceed the purchased cluster bandwidth. For details, see Traffic Throttling Mechanisms.
2. The bandwidth percentage metric uses a peak shifting method to present the utilization of the current cluster. Our calculation method is to obtain the average per unit time, which leads to the above problem.
Why Is Traffic Throttling Not Triggered When the Maximum Production/Consumption Bandwidth Exceeds the Purchased Cluster Bandwidth?
The traffic throttling mechanism of the current cluster employs a relatively soft delayed packet response for high-volume scenarios such as Kafka. In extreme cases, the maximum production/consumption bandwidth of an instance may exceed the purchased cluster bandwidth. For details, see Traffic Throttling Mechanisms.
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 certain cases, such as when the producer version is high and the consumer protocol version is low, leading to protocol conversion during consumption. This can cause higher server pressure. Therefore, it is recommended that customers disable message compression parameters for load testing.
Method to enable configuration: Set compression.type to Snappy or LZ4 in the producer configuration file. The default setting is none.
It is recommended to select Snappy compression first. After the compression is enabled, it may lead to an increase in server CPU and higher production and consumption duration. Proceed with caution.
フィードバック