Modifying Topic Configurations

Last updated:2026-01-20 16:52:40

Modifying Topic Configurations

Last updated: 2026-01-20 16:52:40

After creating a topic, you can modify its configuration based on your business requirements, for example, adjusting such key parameters as the number of partitions and message retention policy, to optimize message throughput performance and enhance data reliability.
Constraints and Limitations
After a topic is created, the topic name cannot be modified.
Operation Steps
1. Log in to the TDMQ for CKafka (CKafka) console.
2. In the left sidebar, click Instance List, and click ID/Name of the target instance to go to the instance details page.
3. On the instance details page, click the Topic List tab. On the topic list page, click Edit in the Operation column.
4. Modify the topic configuration information in the pop-up window.
Parameter
Description
Remarks
Enter the topic description, with a string of no more than 64 characters.
Partition Count
This is a concept of physical partitioning. A topic can contain one or more partitions, and CKafka uses partitions as the assignment unit. The default deployment architecture requires at least 3 nodes. It is recommended to start with 3 partitions to ensure a more even distribution of data. For partition configuration, see Configuring Client Parameters.
Tag
Tags are used to categorize and manage resources from different dimensions. For the detailed introduction, see Configuring Resource Tags.
retention.ms
The message retention period at the topic dimension is 3 days by default, ranging from 1 minute to 90 days. Messages that exceed the configured retention period are deleted to free up disk space.
5. (Optional) Click Advanced Configuration to unfold it and set the following parameters:
Parameter Name
Description
Message Timestamp Type
Define the timestamp type in messages:
CreateTime: The time when the producer creates this message. Since there may be discrepancies between the client time and the server time, you need to check whether the time of writing is accurate.
LogAppendTime: The time when the server broker receives the message.
Preset ACL Policy
Once enabled, you can select the preset access control list (ACL) policies in the drop-down list. For details, see Configuring Topic Read/Write Permissions.
cleanup.policy
Cleanup policies for topic logs:
delete: Logs are deleted based on the retention period. Messages are saved according to the configured message retention period. When disk space is insufficient, old data is automatically cleaned up to ensure service availability. This is suitable for normal message queue scenarios.
compact: Logs are compressed by key to ensure that only the latest value is retained for messages with the same key. This is suitable for scenarios such as status recovery after system crashes or cache reloading upon system restart. For example, when using Kafka Connect or Confluent Schema Registry, Kafka Compact Topic is required to store system status information or configuration information.
delete.compact: This is a combined policy. First, compress keys to retain the latest value, and then delete expired data. It is suitable for mixed data types such as social message streams.
min.insync.replicas
This specifies the minimum number of in-sync replicas (ISRs) that a producer shall successfully write when sending a message. The value ranges from 1 to the maximum number of replicas configured for the topic. Higher values provide stronger data security (tolerating more node failures) while reducing availability (the service becomes unwritable when the number of ISRs falls below the threshold).
When the producer sets request.required.acks to 1, min.insync.replicas is specified as the minimum number of replicas.
unclean.leader.election.enable
Whether to allow electing a new leader from out-of-sync replicas (OSRs).
true (default): allows electing a leader from the OSRs, prioritizing availability.
false: only allows electing a leader from ISRs, prioritizing data consistency.
segment.ms
The duration for segment rolling, ranging from 1 to 90 days, with the minimum unit in ms.
retention.bytes
The message retention size at the partition dimension, ranging from 1 to 1024 GB.
The number of partitions is multiplied by retention.bytes equals the message retention size for the current topic. For a given topic, if both message retention period and size are configured, messages will be retained based on whichever threshold is reached first.
max.message.bytes
The maximum allowed size for a single message, ranging from 1 KB to 12 MB. When sending data, the client aggregates messages destined for the same partition and transmits them together, while the server compares the size of each batch of messages.
6. Click Submit to complete the modification.

Was this page helpful?

You can also Contact Sales or Submit a Ticket for help.

Yes

Feedback

Parameter	Description
Remarks	Enter the topic description, with a string of no more than 64 characters.
Partition Count	This is a concept of physical partitioning. A topic can contain one or more partitions, and CKafka uses partitions as the assignment unit. The default deployment architecture requires at least 3 nodes. It is recommended to start with 3 partitions to ensure a more even distribution of data. For partition configuration, see Configuring Client Parameters.
Tag	Tags are used to categorize and manage resources from different dimensions. For the detailed introduction, see Configuring Resource Tags.
retention.ms	The message retention period at the topic dimension is 3 days by default, ranging from 1 minute to 90 days. Messages that exceed the configured retention period are deleted to free up disk space.

Parameter Name	Description
Message Timestamp Type	Define the timestamp type in messages: CreateTime: The time when the producer creates this message. Since there may be discrepancies between the client time and the server time, you need to check whether the time of writing is accurate. LogAppendTime: The time when the server broker receives the message.
Preset ACL Policy	Once enabled, you can select the preset access control list (ACL) policies in the drop-down list. For details, see Configuring Topic Read/Write Permissions.
cleanup.policy	Cleanup policies for topic logs: delete: Logs are deleted based on the retention period. Messages are saved according to the configured message retention period. When disk space is insufficient, old data is automatically cleaned up to ensure service availability. This is suitable for normal message queue scenarios. compact: Logs are compressed by key to ensure that only the latest value is retained for messages with the same key. This is suitable for scenarios such as status recovery after system crashes or cache reloading upon system restart. For example, when using Kafka Connect or Confluent Schema Registry, Kafka Compact Topic is required to store system status information or configuration information. delete.compact: This is a combined policy. First, compress keys to retain the latest value, and then delete expired data. It is suitable for mixed data types such as social message streams.
min.insync.replicas	This specifies the minimum number of in-sync replicas (ISRs) that a producer shall successfully write when sending a message. The value ranges from 1 to the maximum number of replicas configured for the topic. Higher values provide stronger data security (tolerating more node failures) while reducing availability (the service becomes unwritable when the number of ISRs falls below the threshold). When the producer sets request.required.acks to 1, min.insync.replicas is specified as the minimum number of replicas.
unclean.leader.election.enable	Whether to allow electing a new leader from out-of-sync replicas (OSRs). true (default): allows electing a leader from the OSRs, prioritizing availability. false: only allows electing a leader from ISRs, prioritizing data consistency.
segment.ms	The duration for segment rolling, ranging from 1 to 90 days, with the minimum unit in ms.
retention.bytes	The message retention size at the partition dimension, ranging from 1 to 1024 GB. The number of partitions is multiplied by retention.bytes equals the message retention size for the current topic. For a given topic, if both message retention period and size are configured, messages will be retained based on whichever threshold is reached first.
max.message.bytes	The maximum allowed size for a single message, ranging from 1 KB to 12 MB. When sending data, the client aggregates messages destined for the same partition and transmits them together, while the server compares the size of each batch of messages.

tencent cloud

Constraints and Limitations

Operation Steps