- Subscribe to RSS Feed
- Mark Question as New
- Mark Question as Read
- Float this Question for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
kafka delete doesnt work
- Labels:
-
Apache Kafka
Created ‎08-08-2016 10:18 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
We are using kafka 0.9 and delete.topic.enable=true is set .After we delete topic, it shows "marked for deletion" but it still shows under topic list. After restarting brokers, it is gone.
Does that mean deleting a topic requires restart or some configuration property is missing.
Thanks in advance.
Created ‎08-09-2016 04:29 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- did you set delete.topic.enable=true for all brokers?
- some topic may be undeletable in .9. fixed in .9.1. jira here
- when you made the delete.topic.enable=true, did you restart ZK and Kafka brokers?
Created ‎09-14-2016 06:37 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Please set the delete.topic.enable=true for all brokers
- It is correct behavior as move to 'Marked for deletion" after delete the topic.
- It actual wait for delete as per log.retention.bytes or (delete.retention.ms)
- No need to restart ZK or Kafka brokers.
- It will be automatically reflected.
- You can see the topic using the -list command in "/bin/kafka-topics.sh --list --zookeeper localhost:2181"
Created ‎04-24-2017 06:27 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Although an old post, updating here for any future visitors: This issue occurs in most cases due to one or more of the brokers being unavailable, if not any of the above mentioned ones.
The controller node completes a topic deletion only after all the topic's partition replicas are removed from all the brokers.
So validate that brokers that are currently online by checking the following znode, since sometimes although the broker processes are in running status, they may not be actually part of the cluster because of various reasons such as memory contention and continuous GC cycles:
zk> ls /brokers/ids
