How to remove topics to be deleted when deletion of topics is not enabled?

[#1]

Assume that delete topic request was already issued without knowing that deletion of topics was not yet enabled.

[#2 · Accepted solution]

@Connor O'Neal

When using the command line tools to delete a topic, this is done by creating a Zookeeper node that requests the deletion. Under normal circumstances, this is executed by the cluster immediately. However, the command line tool has no way to know whether or not deletion of topics is enabled in the cluster. As a result, it will request deletion of topics regardless, and if the property is not enabled, this can be waiting. It is possible to delete the requests pending for deletion of topics to avoid this. Topics are requested for deletion by creating a Zookeeper node as a child under /admin/delete_topic that is named with the topic name. Deleting these Zookeeper nodes (but not the parent /admin/delete_topic node) will remove the pending requests. Then you change your property to allow deletes and re-execute topic delete requests.

+++

Hopefully this response helped. Please vote/accept as best answer.

[#3]

Can you please provide the commands on how to login to zookeeper nodes and to delete the topics. Am also stuck at the step which says "topic is marked for deletion".

[#4]

@Connor O'Neal

In order to login to zookeeper node you can use below command

# /usr/hdp/current/zookeeper-server/bin.zkCli.sh  -server <hostname>:2181

Although the kafka delete command may seem like it deletes topics and returns successfully, in fact behind the scene it creates - " /admin/delete_topics/<topic> " node in zookeeper and only triggers deletion.

We can verify this by checking the same via "zkCli.sh" as below:

# cd /usr/hdp/current/zookeeper-server/bin/
# ./zkCli.sh -server <hostname>:2181
[zk: <broker-hostname>:2181 (connected)] ls /
[zk: <broker-hostname>:2181 (connected)] ls /admin [zk: <broker-hostname>:2181 (connected)] ls /admin/delete_topics

As soon as broker sees this update, the topic no longer accepts any new produce/consume requests and eventually the topic will be deleted.

1. Topic Command issues topic deletion by creating a new admin path - "/admin/delete_topics/<topic>". 2. The controller listens for child changes on /admin/delete_topic and starts topic deletion for the respective topics 3. The controller has a background thread that handles topic deletion. The purpose of having this background thread is to accommodate the TTL feature, when we have it. This thread is signaled whenever deletion for a topic needs to be started or resumed. Currently, a topic's deletion can be started only by the onPartitionDeletion callback on the controller. In the future, it can be triggered based on the configured TTL for the topic.

A topic will be ineligible for deletion in the following scenarios -

a. broker hosting one of the replicas for that topic goes down b. partition reassignment for partitions of that topic is in progress c. preferred replica election for partitions of that topic is in progress (though this is not strictly required since it holds the controller lock for the entire duration from start to end) 4. Topic deletion is resumed when - a. broker hosting one of the replicas for that topic is started b. preferred replica election for partitions of that topic completes c. partition reassignment for partitions of that topic completes

[#5]

@amankumbare thanks for the detailed explanation