Modifying Topic Configurations

Last updated: 2025-09-19 17:33:13

Modifying Topic Configurations

Last updated: 2025-09-19 17:33:13

After the Topic is created, you can modify the Topic configuration based on your business needs, such as adjusting the number of partitions and message retention policy, to optimize throughput performance and enhance data reliability.
Constraints and Limitations
The Topic name cannot be modified after creation.
Operation Steps
1. Log in to the CKafka console.
2. Click in the left sidebar instance list, click the ID/Name of the target instance, and enter 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 bar.
4. Modify Topic configuration in the pop-up window.
Parameter
Description
Remarks
Fill in the Topic description, no more than 64 characters.
Number of Partitions
The concept of a physical partition. A Topic can contain one or more partitions. CKafka uses partitions as the allocation unit. The default deployment architecture requires at least 3 nodes. It is recommended to start with 3 partitions for more balanced data distribution. Refer to the document Parameter Configuration Instructions for partition number configuration.
Tag
Tags are used to categorize and manage resources from different dimensions. For more details about tags, see Tag Management.
retention.ms
The message retention period at the Topic level defaults to 3 days, with a range of 1 minute to 90 days. Messages will be deleted after exceeding the set retention duration to preserve sufficient disk space.
5. (Option) Click to expand advanced configuration and set the following parameters:
Parameter Name
Description
message timestamp type
Define the message timestamp type:
CreateTime: The time when the producer created this message. Since the client time may deviate from the server time, check whether the written time is correct.
LogAppendTime: The time when the server-side Broker receives the message.
Preset ACL policy
Once enabled, you can select the preconfigured ACL policy in the dropdown list. For details, see Configuring ACL Policy.
cleanup.policy
Topic log cleanup policy:
Logs are deleted based on retention time. Messages are stored according to the configured message retention period. Old data is automatically cleaned up when disk capacity is insufficient to ensure service availability. Suitable for normal message queue scenarios.
Logs are compacted by Key to ensure only the latest Value is kept for identical keys. Suitable for recovery status after system downtime, reloading cache after system restart, and other scenarios. For example, when using Kafka Connect or Confluent Schema Registry, Kafka compact Topic is required to store system status or configuration messages.
delete.compact: A combined policy that first compresses keys to retain the latest value, then deletes expired data. Suitable for hybrid data such as social message flow.
min.insync.replicas
Specify the minimum number of in-sync replicas (ISR) that must successfully receive messages sent by the producer. The value ranges between 1 and the maximum number of replicas for the Topic. A higher value provides higher security (tolerating more node faults) but reduces availability (service becomes unwritable when ISR is not sufficient).
When the producer sets request.required.acks to 1, min.insync.replicas specifies the minimum number of replicas.
unclean.leader.election.enable
Whether to allow electing a new Leader from Out-of-Sync Replicas (OSR).
true (default): Allow electing a Leader from OSR, giving priority to availability.
false: Only allow electing a Leader from In-Sync Replicas (ISR), giving priority to data consistency.
segment.ms
The duration for Segment sharding ranges from 1 to 90 days, with a minimum unit of ms.
retention.bytes
Message retention size per partition, ranging from 1 to 1024 GB.
Number of partitions * retention.bytes = message retention size of the current Topic. For a Topic, if both message retention period and message retention size are set, the actual message retention will follow whichever threshold is reached first.
max.message.bytes
Maximum size for a single message, ranging from 1 KB to 12 MB. When sending data, the client aggregates data sent to the same partition into batches. The server compares the size of each batch.
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	Fill in the Topic description, no more than 64 characters.
Number of Partitions	The concept of a physical partition. A Topic can contain one or more partitions. CKafka uses partitions as the allocation unit. The default deployment architecture requires at least 3 nodes. It is recommended to start with 3 partitions for more balanced data distribution. Refer to the document Parameter Configuration Instructions for partition number configuration.
Tag	Tags are used to categorize and manage resources from different dimensions. For more details about tags, see Tag Management.
retention.ms	The message retention period at the Topic level defaults to 3 days, with a range of 1 minute to 90 days. Messages will be deleted after exceeding the set retention duration to preserve sufficient disk space.

Parameter Name	Description
message timestamp type	Define the message timestamp type: CreateTime: The time when the producer created this message. Since the client time may deviate from the server time, check whether the written time is correct. LogAppendTime: The time when the server-side Broker receives the message.
Preset ACL policy	Once enabled, you can select the preconfigured ACL policy in the dropdown list. For details, see Configuring ACL Policy.
cleanup.policy	Topic log cleanup policy: Logs are deleted based on retention time. Messages are stored according to the configured message retention period. Old data is automatically cleaned up when disk capacity is insufficient to ensure service availability. Suitable for normal message queue scenarios. Logs are compacted by Key to ensure only the latest Value is kept for identical keys. Suitable for recovery status after system downtime, reloading cache after system restart, and other scenarios. For example, when using Kafka Connect or Confluent Schema Registry, Kafka compact Topic is required to store system status or configuration messages. delete.compact: A combined policy that first compresses keys to retain the latest value, then deletes expired data. Suitable for hybrid data such as social message flow.
min.insync.replicas	Specify the minimum number of in-sync replicas (ISR) that must successfully receive messages sent by the producer. The value ranges between 1 and the maximum number of replicas for the Topic. A higher value provides higher security (tolerating more node faults) but reduces availability (service becomes unwritable when ISR is not sufficient). When the producer sets request.required.acks to 1, min.insync.replicas specifies the minimum number of replicas.
unclean.leader.election.enable	Whether to allow electing a new Leader from Out-of-Sync Replicas (OSR). true (default): Allow electing a Leader from OSR, giving priority to availability. false: Only allow electing a Leader from In-Sync Replicas (ISR), giving priority to data consistency.
segment.ms	The duration for Segment sharding ranges from 1 to 90 days, with a minimum unit of ms.
retention.bytes	Message retention size per partition, ranging from 1 to 1024 GB. Number of partitions * retention.bytes = message retention size of the current Topic. For a Topic, if both message retention period and message retention size are set, the actual message retention will follow whichever threshold is reached first.
max.message.bytes	Maximum size for a single message, ranging from 1 KB to 12 MB. When sending data, the client aggregates data sent to the same partition into batches. The server compares the size of each batch.

tencent cloud

Constraints and Limitations

Operation Steps