Changing Instance Specifications
Last updated:2026-01-20 17:02:40
Scenarios
If the current instance specifications do not meet your business requirements, you can upgrade them in the console based on your business requirements.
Configuration Change Type | Change Item | Standard Edition (Discontinued) | Advanced Edition | Pro Edition |
Upgrading instance specifications | Peak bandwidth | × | ✓ | ✓ |
| Disk capacity | × | ✓ | ✓ |
| Partition limit | × | ✓ | ✓ |
Downgrading instance specifications | Peak bandwidth | × | ✓ | ✓ |
| Disk capacity | × | ✓ | ✓ |
| Partition limit | × | ✓ | ✓ |
Changing the instance specification type | / | Supports upgrading to Advanced Edition/Pro Edition. | × | × |
Note:
TDMQ for CKafka (CKafka) Standard Edition instances were no longer offered for sale since March 2024. It is recommended that you upgrade your instances to Pro Edition, which supports multi-availability zone (AZ) deployment and higher SLA guarantees, and now supports more advanced features, including diverse storage types, SSL authentication, and intelligent Ops.
Configuration Change Impacts
After you select the target instance specifications for the configuration change, the system will automatically determine whether the underlying resources need to be changed and whether data migration is necessary. During the data migration process, after each partition is migrated, partition leader switching will be performed. For risks associated with leader switching, see Typical Scenarios of Leader Switching.
If a topic has only one replica, since it lacks redundant backups, it will become completely unavailable during the change, preventing any message production or consumption operations and posing a risk of business interruption.
If a topic has multiple replicas, it can maintain service continuity during the change, but nodes need to be restarted one by one. The load will be transferred to other available nodes. Therefore, it is recommended to schedule the change operation during off-peak hours.
During the change, the monitoring process may be partially lost or temporarily interrupted due to rolling node restarts, resulting in inaccurate or missing monitoring data. Data monitoring returns to normal after node restarts.
During the change, rolling node restarts will trigger partition leader re-elections, causing second-level momentary disconnections. Under stable network conditions, leader switching typically completes within 1 minute. To ensure the service reliability of the multi-replica topic, it is recommended to configure a retry mechanism in production clients:
For scenarios using the Kafka open-source client, check the configuration of the retries parameter. It is recommended to set it to 3–5.
For environments using the Flink client, verify whether an appropriate restart policy has been configured.
During the configuration change, ports may change. The actual IP address for public network communication may change (the access point address remains unchanged), while both the actual IP address for private network communication and the access point address remain unchanged. You can log in to the CKafka console, select Instance List in the left sidebar, and click the instance ID to go to the details page. Then, choose Access Method > View All IP Addresses and Ports. If your server has access restrictions (security groups) configured, reset the port range on the server. For specific operations, see Binding a Security Group.
Note:
Access address: Access addresses refer to the network connection addresses displayed in the CKafka access point details. The port numbers typically range from 50000 to 53000. Normally, access addresses are not changed due to configuration changes.
Communication address: Communication addresses refer to the IP addresses and ports displayed after you click View All IP Addresses and Ports on the right side of the CKafka access point details. These IP addresses and ports are used for data transmission between clients and CKafka. They typically change during configuration changes involving data migration.
Both access addresses and communication addresses require allowing relevant addresses and ports in the firewall.
During cluster configuration changes, it is recommended to avoid operating features related to topic management, such as creating topics or editing topic properties. The specific feature list is as follows:
Feature Module | Specific Feature | Description |
Topic management list | Creating a topic | Create a topic in the cluster. |
| Editing a topic | Edit the properties of a topic in the cluster, such as changing the number of partitions or the number of replicas. |
| Deleting a topic | Delete a topic in the cluster. |
| Throttling traffic | Configure a traffic throttling policy for topics. |
| Performing manual partition balancing for traffic diversion | Perform manual partition balancing for traffic diversion to resolve the issue of uneven partition distribution. |
Intelligent Ops (a feature exclusive to Pro Edition) | Adjusting the disk watermark | Change the dynamic message retention policy or the switch status of automatic disk capacity expansion. |
| Performing dynamic partitioning | Perform manual partition balancing for traffic diversion or configure an automatic partition balancing policy. |
| Configuring elastic bandwidth | Change the switch status of elastic bandwidth. |
When you upgrade a yearly/monthly subscription instance, you need to pay the price difference on a daily basis. For details, see Yearly/Monthly Subscription and Product Configuration Upgrades.
Note:
Since configuration changes may alter instance specifications, certain monitoring metrics (percentage-based) may fluctuate. For example, if you downgrade a disk from 2000 GB to 1000 GB, disk utilization may exceed 100%. This condition automatically returns to normal after the configuration change completes. It is recommended to focus on capacity-related metrics (such as disk usage) during the configuration change process.
Prerequisites
You have completed the following check items before performing a configuration change:
1. Check whether the instance has unavailable Virtual Private Cloud (VPC) networks, public network routes, or supporting networks. For details, see Network Connection Instructions.
2. Check whether the instance has unsynchronized replicas. For details, see Viewing Partition Status of Topics.
3. Check whether the instance has incomplete tasks (such as data migration) or abnormally created/deleted topic data.
4. Check whether the remaining disk space is sufficient or enable automatic disk capacity expansion (a feature exclusive to Pro Edition) before upgrading peak bandwidth. Disk capacity expansion cannot be initiated concurrently during instance configuration changes, as full disk load may cause traffic throttling.
5. Check the resource usage of the instance in at least the last 7 days before downgrading the specifications. If the peak bandwidth or peak storage of the instance in the last 7 days exceeds the target downgrade specifications, proceeding with the downgrade may cause damage to your business. Decide whether to perform the downgrade operation based on your actual business requirements.
Note:
If any of the above items or tasks are not yet completed, it is recommended to wait until all of them are completed before proceeding with the configuration change. If an exception occurs during task execution, contact the online customer service of Tencent Cloud for assistance.
Operation Steps
1. Log in to the CKafka console.
2. In the left sidebar, select Instance List, locate the target instance, and choose More > Upgrade in the Operation column.
3. On the configuration upgrade page, select the target specifications based on your business requirements.
Set the target peak bandwidth, disk capacity, and partition limit.
Set the specification type to Pro Edition, and set the target peak bandwidth, disk capacity, and partition limit.
4. Click Next to set the change mode.
If it is identified that the configuration change does not require data migration, you do not need to set the change mode and can directly go to the next step.
If it is identified that the configuration change requires data migration, you can set the change time and change mode.
Change Time: You can select Execute or Custom (it is recommended to schedule the execution at night to reduce the impact on your business).
Change Mode: You can select a configuration change mode based on actual business requirements.
Stable Mode: CKafka will limit the data migration speed during configuration changes to preserve the bandwidth properties of the instance to the greatest extent. This mode is suitable for scenarios where business disruption is undesirable.
High-Speed Mode: CKafka will impose no restrictions on the data migration speed during configuration changes, which may affect the production and consumption bandwidth of the instance. This mode is suitable for off-peak hours or scenarios where service suspension is acceptable.
5. Click Submit and return to the instance list, and you can see that the instance status has changed to Modifying. Click the tooltip to view the configuration change progress of the instance. If a scheduled configuration change is set, you can modify the scheduled time in the Status column.
1. Log in to the CKafka console.
2. In the left sidebar, select Instance List, locate the target instance, and choose More > Downgrade in the Operation column.
3. On the configuration downgrade page, select the target specifications based on your business requirements.
4. Click Next to set the change mode.
If it is identified that the configuration change does not require data migration, you do not need to set the change mode and can directly go to the next step.
If it is identified that the configuration change requires data migration, you can set the change time and change mode.
Change Time: You can select Immediately or Custom Time (it is recommended to schedule the execution at night to reduce the impact on your business).
Change Mode: You can select a configuration change mode based on actual business requirements.
Stable Mode: CKafka will limit the data migration speed during configuration changes to preserve the bandwidth properties of the instance to the greatest extent. This mode is suitable for scenarios where business disruption is undesirable.
High-Speed Mode: CKafka will impose no restrictions on the data migration speed during configuration changes, which may affect the production and consumption bandwidth of the instance. This mode is suitable for off-peak hours or scenarios where service suspension is acceptable.
5. Click Submit and return to the instance list, and you can see that the instance status has changed to Modifying. Click the tooltip to view the configuration change progress of the instance. If a scheduled configuration change task is set, you can modify the scheduled time in the Status column.
Possible Reasons for Upgrade Failures
1. The current AZ lacks sufficient disk resources for this upgrade. It is recommended to contact the online customer service of Tencent Cloud to confirm whether sufficient resources are available.
2. During an instance upgrade in the high-speed mode, prolonged data migration delays may occur if bandwidth-intensive production tasks exist in the cluster. You can observe whether abnormal peaks exist in production and consumption traffic during the upgrade period.
3. The configuration upgrade takes too much time because the target broker for migration is configured with a maximum message size of 1 MB, while the broker to be migrated is configured with a message size of 8 MB. As a result, the target broker cannot receive the oversized messages to be migrated, resulting in prolonged data migration duration. Consult the online customer service of Tencent Cloud for assistance.
4. During the configuration upgrade of a cluster or its migration to a new cluster, an exception in the broker IP address update causes the failure to pull data via the broker IP address of the new cluster. By viewing monitoring data, you can observe that the monitoring data for a period of time is missing. Consult the online customer service of Tencent Cloud for assistance.
How Do I Improve the Configuration Change Speed
The configuration change speed is largely dependent on the configuration and data volume of the current instance. It is recommended to modify the data retention period of the topic or increase the number of partitions in advance. Shortening the data retention period or increasing the number of partitions appropriately can effectively reduce the configuration change time and improve the configuration change efficiency.
Was this page helpful?
You can also Contact Sales or Submit a Ticket for help.
Yes
No
Feedback