Creating Topic
Last updated:2026-01-20 16:52:40
Scenarios
A topic is a category name for storing messages. Producers write messages to a topic, while consumers read messages from it. To achieve horizontal scaling, a topic is physically composed of multiple partitions. When you encounter bottlenecks, you can achieve horizontal scale-out by increasing the number of partitions.
Constraints and Limitations
When the total number of partitions for all topics (manually and automatically created topics) under an instance reaches the upper limit, you will be unable to create new topics. In this case, you can increase the number of partitions to increase the topic quota.
Prerequisites
A TDMQ for CKafka (CKafka) instance has been created in advance. For detailed operations, see Creating an Instance.
Operation Steps
1. Log in to the CKafka console.
2. In the left sidebar, select Instance List, select an instance, and click ID/Name of the target instance to go to the instance details page.
3. On the instance details page, select the Topic List tab on the left side of the page, and click Create.
4. In the topic editing window, set information about the topic, such as the number of partitions and the number of replicas.
Parameter | Required | Description |
Name | Yes | Fill in the topic name. The name must comply with naming rules: it can only contain letters, numbers, underscores (_), hyphens (-), and periods (.), and cannot start with double underscores (__). The topic name cannot be changed after creation. |
Remarks | No | Enter the topic description, with a string of no more than 64 characters. |
Number of Partitions | Yes | 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. |
Number of Replicas | Yes | This is the number of replicas for a partition, which ensures high availability of the partition. To guarantee data reliability, two replicas are enabled by default. Replicas are also counted as partitions. For example, if a customer creates 1 topic with 6 partitions and 2 replicas for each topic, the total partition quota is: 1 x 6 x 2 = 12. Note: Setting to a single replica may cause unavailability. Proceed with caution. |
Tag | No | Tags are used to categorize and manage resources from different dimensions. For the detailed introduction, see Configuring Resource Tags. |
retention.ms | Yes | 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 | Default Value | Description |
Message Timestamp Type | LogAppendTime (recommended) | 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 | Disabled | 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 | delete | 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 | 1 | 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 | true | 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 | Message retention size for the instance by default | 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. (This parameter is not currently configurable for serverless instances.) |
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 creation.
Automatic topic creation means that when a client produces or consumes messages for a topic, the system automatically checks whether the topic exists. If the topic does not exist and its name complies with naming rules (it can only contain letters, numbers, underscores (_), hyphens (-), and periods (.), and cannot start with double underscores (__)), the system will automatically create this topic. The default parameter values for this topic are as shown in the table.
Parameter | Default Value |
Number of Partitions | Set this parameter when the automatic topic creation is enabled, with at least 3 nodes by default. |
Number of Replicas | Set this parameter when the automatic topic creation is enabled, with 2 replicas by default. |
Default Message Retention Period | 3 days by default. The default value can be modified by setting topic global properties. For specific operations, see Configuring Topic Global Properties. |
Default Maximum Message Size | 8 MB by default. The default value can be modified by setting topic global properties. For specific operations, see Configuring Topic Global Properties. |
UncleanLeaderElectionEnable | true by default, which controls whether to allow OSRs to be elected as a leader. The default value can be modified by setting topic global properties. For specific operations, see Configuring Topic Global Properties. |
Message Timestamp Type | LogAppendTime by default, indicating the time when the server broker receives the message. |
cleanup.policy | delete by default, which means logs are deleted based on the retention period. |
min.insync.replicas | 1 by default, which specifies the minimum number of ISRs that shall be successfully written to when a producer sends messages. |
Enabling Automatic Topic Creation
1. Log in to the CKafka console.
2. In the left sidebar, select Instance List, select an instance, and click ID/Name of the target instance to go to the instance details page.
3. In the Auto- Create Topic module, click the Configuration button in the upper-right corner to enable Auto-Create Topic.
4. Set the number of partitions and replicas for the topic and click Submit to complete the configuration.
The configurations of automatically created topics under this instance inherit the configured numbers of partitions and replicas.
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.
Replica Count: This is the number of replicas for a partition, which ensures high availability of the partition. To guarantee data reliability, two replicas are enabled by default. Replicas are also counted as partitions. For example, if a customer creates 1 topic with 6 partitions and 2 replicas for each topic, the total partition quota is: 1 x 6 x 2 = 12.
Note:
Setting to a single replica may cause unavailability. Proceed with caution.
Modifying Topic Configurations
For automatically created topics, if the default parameter values do not meet your business requirements, you can manually modify the topic configuration. For specific operations, see Modifying Topic Configurations.
Was this page helpful?
You can also Contact Sales or Submit a Ticket for help.
Yes
No
Feedback