Creating Topic
Last updated: 2025-09-19 17:33:13
Scenarios
A Topic is the name of a certain category used for storing messages. Producers write messages to topics, and consumers read messages from topics. To achieve horizontal expansion, a Topic is composed of multiple Partitions. When encountering a bottleneck, horizontal scale-out can be performed by increasing the number of Partitions.
Restrictions and Limitations
When the total number of partitions for all topics (including manually and auto-created topics) under an instance reaches the Partition cap, you will not be able to create more topics. You can expand the number of partitions to increase the Topic limit.
Prerequisites
Operation Steps
1. Log in to the CKafka console.
2. Choose Instance List in the left sidebar, select the target instance, then click the ID/Name of the target instance to enter the instance details page.
3. On the instance details page, select the Topic list tab on the left side and click Create.
4. In the edit Topic window, set the number of partitions and the number of replicas, information, etc.
Parameter | Required or Not | Description |
Name | Yes | Fill in the Topic name. The name must comply with the naming rule: it can only contain letters, digits, underscores, "-", and ".". It does not support names starting with "double underscores". The Topic name cannot be changed once created successfully. |
Remarks | No | Fill in the Topic description, no more than 64 characters. |
Number of Partitions | Yes | 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 advisable to start with 3 partitions for more balanced data distribution. For partition configuration, refer to the Parameter Configuration Instructions. |
Number of Replicas | Yes | The number of replicas in a Partition is used to ensure high availability of the Partition. To ensure data reliability, 2 replicas are enabled by default. The number of replicas is also counted as the number of partitions. For example, if a customer creates a Topic with 6 partitions and 2 replicas, the total Partition limit used is 1 × 6 × 2 = 12. Note: Warning: Setting to single replica can cause availability issues. Proceed with caution. |
Tag | No | Tags are used to categorize and manage resources from different dimensions. For more details about tags, see Tag Management. |
retention.ms | Yes | 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 to preserve sufficient disk space once the retention duration is exceeded. |
5. (Optional) Click to expand advanced configuration 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 created this message. Since the client time may deviate from server time, you need to check whether the written time is correct. LogAppendTime: The time when the server-side Broker receives the message. |
Preset ACL policy | Disable | Once enabled, you can select the preconfigured ACL policy in the dropdown list. For details, see Configuring ACL Policies. |
cleanup.policy | delete | Topic log cleanup policy: delete: Logs are deleted based on retention time. Messages are stored according to the configured message retention period. Old data is automatically cleaned up in case of insufficient disk capacity to ensure service availability. Suitable for normal message queue scenarios. compact: Logs are compressed by Key to ensure only the latest Value is kept for identical keys. Suitable for recovery status after system downtime and reloading cache after system restart. For example, when using Kafka Connect or Confluent Schema Registry, require the use of Kafka compact Topic to store system status or configuration messages. delete.compact: Combined policies, compress keys to retain the latest value, then delete expired data. Suitable for hybrid data such as social message flow. |
min.insync.replicas | 1 | 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 improves data 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 | true | 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 | - | Segment fragment scrolling duration, ranging from 1 to 90 days, with a minimum unit of ms. |
retention.bytes | Defaults to the instance's message retention size | Message retention size by 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. (This parameter cannot be configured for Serverless instances.) |
max.message.bytes | - | The upper limit for a single message is 1KB to 12MB. 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 creation.
"Automatically Create Topics" means when a client produces or consumes messages to a topic, it will automatically detect the topic's existence. If the topic does not exist and its name complies with the naming rule (can only contain letters, numbers, underscore, "-", and ".", no support for starting with double underscores), the system will automatically create this topic. The default parameter values for this topic are as shown in the table below.
Parameter | Default Value |
Number of Partitions | Enable automatic Topic creation with a default of at least 3 nodes. |
Number of Replicas | Enable automatic Topic creation with a default of 2 replicas. |
Default message retention time | Default is 3 days. The default value can be modified by setting the Topic global attribute. For specific operations, refer to Configure Topic Global Attribute. |
Default max message size | Default is 8 MB. The default value can be modified by setting the Topic global attribute. For specific operations, refer to Configure Topic Global Attribute. |
UncleanLeaderElectionEnable | Set to true by default to control whether to allow unsynchronized replicas to be selected as Leader. The default value can be modified by setting the Topic global attribute. For specific operations, refer to Configure Topic Global Attribute. |
Message Timestamp Type | Defaults to LogAppendTime, representing the time when the server-side Broker receives the message. |
cleanup.policy | Defaults to delete. Logs are deleted based on retention time. |
min.insync.replicas | Defaults to 1, used to specify the minimum number of synced replicas (ISR) that must successfully write messages sent by the producer. |
Enabling Auto Topic Creation
1. Log in to the CKafka console.
2. Choose Instance List in the left sidebar, select the target instance, then click the ID/Name of the target instance to enter the instance details page.
3. In the Auto Topic Creation module, click the Configure button in the upper right corner to enable Auto Topic Creation.
4. After setting the number of partitions and the number of replicas for the Topic, click Submit to complete the configuration.
The configuration of auto-created Topics under the instance will inherit the configured number of partitions and replicas.
Number of partitions: A concept of physical partition. A Topic can contain one or more partitions, and CKafka uses partitions as the allocation unit. The default deployment architecture requires at least 3 nodes, with a recommended starting number of partitions of 3 for more balanced data distribution. For partition configuration, refer to the Parameter Configuration Instructions document.
Number of replicas: The replica count of a Partition, used to ensure high availability of the Partition. To ensure data reliability, 2 replicas are enabled by default. The number of replicas is also counted as the number of partitions. For example, if a customer created 1 Topic with 6 partitions and 2 replicas, then the total Partition limit used is 1 × 6 × 2 = 12.
Note:
Warning: Setting to single replica can cause availability issues. Proceed with caution.
Modifying Topic Configurations
For auto-created Topics, if the default configured parameters do not meet your business needs, you can manually modify the Topic Configuration. For specific operations, refer to Modify Topic Configuration.
Was this page helpful?
You can also Contact Sales or Submit a Ticket for help.
Yes
No
Feedback