Once a topic exists, you can change its partitions, replication factor and settings, empty it, start it again from scratch, or remove it. All four actions work on the topic selected in the topics list, from the buttons above the topic's tabs or from the topics list's right-click menu.
- Clear Messages: deletes every message and keeps the topic (Clearing all messages). Greyed out here because
customer-profilesis a compacted topic. - Edit Settings: opens the Update Topic dialog (Updating a topic).
- Re-create Topic: deletes the topic and creates it again, empty (Re-creating a topic).
- Delete Topic (Deleting a topic).
- The same actions on the right-click menu of a topic in the list. Right-clicking also selects the topic.
Each action asks you to confirm first (except Edit Settings, which opens a dialog) and applies at once, for every producer and consumer of the topic. Clearing, re-creating and deleting can't be undone, so check the topic name in the confirmation, especially on a production cluster. To see what these do to a topic afterwards, use its Overview tab.
Updating a topic
Edit Settings opens Update Topic, the same dialog as Create Topic but filled in with the topic's current values. It has two tabs: Topic Properties for the topic's settings and Advanced for its partitions and replication factor. A topic can't be renamed: to use a different name, create a new topic and move the data yourself.
order-returns-dlq, which has its own retention time and maximum message
size.- Name: shown for reference; it can't be changed.
- Partitions and Replication factor: greyed out on this tab; change them on the Advanced tab.
- Common properties: the topic's current values, whether the topic sets them itself or inherits them from the cluster.
- Update another property: adds a row for any other topic setting.
- Update Topic: applies the whole form.
- Advanced: partitions and replication factor.
Changing topic properties
The Common properties are the five described in Creating Topics. Change a value, or empty a field (<broker default> for the cleanup policy) to remove the topic's own value so it follows the cluster's default again, then click Update Topic. KafkIO says The topic was successfully updated! and leaves the dialog open; close it with Close. Clicking Update Topic without changing anything leaves the topic as it was: values the topic only inherits from Kafka's defaults aren't copied onto it.
Settings the topic already has its own value for (source DYNAMIC_TOPIC_CONFIG on the Settings tab) that aren't on the form are kept.
Update another property lists every topic setting with a search box; the value field
starts at Kafka's usual default, not at the topic's current value, so look that up on the Settings tab first.
- A setting the topic already has its own value for can't be changed with Update
another property: the old value is kept, yet KafkIO reports success. (Setting
compression.typetosnappyon a topic that hadgzipleft it atgzip.) Change such settings one at a time from the Settings tab instead (Updating a setting). - KafkIO works from the topic settings it last read. A topic setting someone added outside KafkIO since then is removed when you click Update Topic. Click Refresh on the topic's Settings tab before opening Update Topic if others may have changed the topic.
To change one setting, or any setting not among the five, the Settings tab is usually quicker. Changing settings needs
AlterConfigs permission on the topic.
Increasing partitions
inventory from 3 to 6 partitions and from 1 to 3 replicas.- The Advanced tab (only available when updating a topic).
- Increase partitions to: the new total, starting at the current count.
- Increase Partitions applies it.
- Update replication factor: the new number of copies, starting at the current one.
- Set Replication Factor applies it.
Set the new total with the spinner's arrows (or the ↑ and ↓ keys; you can't type a number here) and click Increase Partitions. Each button applies only its own row, straight away, and KafkIO confirms with The topic partition count was successfully updated!.
Kafka can add partitions but never remove them. Asking for fewer, or the same number, fails with an error such as Topic currently has 6 partitions, which is higher than the requested 5. Existing messages stay where they are and the new partitions start empty:
- Keyed messages move. Producers choose a partition from the key and the partition count, so after the change most keys go to a different partition than before. Messages for one key are then split across two partitions, and a consumer can see a key's newer messages before its older ones. If your consumers rely on per-key order (or the topic is compacted), plan the change: drain or pause producers first, or create a new topic with the right count.
- Consumers pick up the new partitions at their next rebalance, which can take a few minutes
for producers and consumers to notice. A consumer group with
auto.offset.reset=latest(Kafka's default) can skip messages written to a new partition before it was assigned.
Changing the replication factor
Pick the new number of copies next to Update replication factor and click Set Replication Factor. You can go up or down, from 1 to the number of brokers in the cluster, so a single-broker cluster can only have 1. KafkIO refuses anything else (Requested replication factor 4 more than brokers count 3., Topic already has replicationFactor 3.).
KafkIO chooses the brokers for you, partition by partition, using only brokers that are online:
- To add copies, it picks the brokers that hold the fewest replicas so far, which keeps the load even.
- To remove copies, it drops them from the busiest brokers first and never removes a partition's current leader.
Kafka then copies the data to the new replicas in the background (a partition reassignment). Until they've caught
up, the topic's partitions show as under-replicated, which is expected: on a large topic it can take a while and
adds network and disk load to the brokers. This needs Kafka 2.4 or later and Alter permission on the
cluster. To see where replicas ended up, or how evenly brokers are loaded, see Brokers.
- Partitions: 6, up from 3.
- Replication Factor: 3, up from 1; each partition now lists three replicas.
- The new partitions 3 to 5, empty until producers write to them.
Clearing all messages
Clear Messages empties a topic but keeps it: its name, partitions, settings and consumer groups stay as they are. Use it to start a test again with a clean topic, or to get rid of messages that should never have been sent. KafkIO asks Are you sure you want to clear all messages on topic ...?; click Clear. A Topic cleared notification follows and the topic's # Msgs drops to 0.
Behind the scenes KafkIO asks Kafka to delete every partition's messages up to its current end. That means:
- Offsets carry on. The next message in a partition gets the next offset, not 0, and the partition's First Offset and Last Offset become equal. Consumer groups' committed offsets stay valid, so consumers simply wait for new messages.
- Messages written while it runs after KafkIO read the end offsets are kept.
- It needs
Deletepermission on the topic.
To start offsets from 0 again, or to drop the topic's settings too, re-create the topic instead.
Compacted topics
Clear Messages is greyed out, on the button and the right-click menu, for a topic whose
cleanup policy is compact. Kafka doesn't
allow deleting messages by offset on a compacted topic: such a topic is meant to keep the latest message for every
key until a newer one (or a null "tombstone") replaces it. Topics with compact,delete can be cleared
as normal.
To empty a compacted topic, re-create it with its settings included, which keeps it compacted.
Re-creating a topic
Re-create Topic deletes the topic and creates it again with the same name, number of partitions and replication factor: a quick way to get a completely fresh topic without retyping its setup. The confirmation asks whether to bring back the topic's own settings.
- Include previously-set DYNAMIC_TOPIC_CONFIG configuration
(recommended): the default. The new topic gets back every setting the old one had its own value for
(those with source
DYNAMIC_TOPIC_CONFIGon the Settings tab), such as its retention or cleanup policy. - Do NOT include previously-set DYNAMIC_TOPIC_CONFIG configuration:
the new topic follows the cluster's defaults for everything. A compacted topic, for example, comes back with
the cluster's default cleanup policy (usually
delete).
Click Re-create. KafkIO deletes the topic, waits a second, then creates it, retrying every second for up to 15 seconds while Kafka finishes the deletion. Topic successfully re-created! confirms it. What the new topic doesn't keep:
- Messages, all of them, and offsets, which start from 0 again.
- Consumer groups' committed offsets for the topic: Kafka removes them with the old topic (a
group that read only this topic disappears from the Consumers list).
Consumers then start from the oldest or newest message according to their
auto.offset.reset. - Replica placement: Kafka assigns the partitions to brokers afresh.
ACLs and Schema Registry subjects for the topic name are separate from the topic, so they still apply to the new one. Re-creating needs topic deletion to be allowed on the cluster, like deleting, plus permission to create topics.
Deleting a topic
Delete Topic removes the topic and all its messages for good. KafkIO asks Are you sure you want to delete topic ...?; after Delete, the topic leaves the topics list and a Deleted topic notification appears. As with re-creating, Kafka also drops consumer groups' committed offsets for it.
Deleting needs:
- Topic deletion allowed on the brokers (
delete.topic.enable, on by default). The cluster's Overview shows it as Topic Deletion; when it's No, KafkIO refuses with Topic deletion restricted. Deletepermission on the topic.
If producers keep writing to the topic and the brokers allow automatic topic creation
(auto.create.topics.enable), the topic comes back, empty and with default settings, the next time one
of them sends a message. Stop the producers first.
Cloud clusters and delayed deletes
After deleting, KafkIO asks the cluster for the topic once more to make sure it's gone. Some cloud services (Confluent Cloud, Amazon MSK and others) take a moment longer to reflect a deletion. If the topic is still there, KafkIO shows Delete topic possible failure and leaves the topic in the list. That usually means the deletion is still going through rather than that it failed: wait a few seconds and refresh the topics list (Refreshing). If it's still listed after that, check the topic deletion setting and your permissions above.