zookeeper-shall.sh rmrブローカー/トピックを使用したトピックの削除とkafka10のkafka-topics.shのフラグの削除

Question

オンラインと他のスタックオーバーフローポストでは、トピックを削除する主に2つの方法があるようですカフカで 最初ビーイング：A）delete.topic.enable = trueと./kafka-topics.sh ---delete --topic <topicName> 第二の方法を実行している：./zookeeper-shell.sh localhost:2181 rmr brokers/topics

Iやった第1の方法は第二の方法は、それらを削除した通りであり、削除やトピックは削除されます数分かけなければ、各トピックをマークすることを予告瞬時にまた、サーバーの再起動に数時間かかりますが、これは正常ですか？私は1つのブローカー（テスト目的のために）に1000以上のトピックを持っていました。

Answer 1

第一の方法は、zookeper admin/delete_topics/<topic>でノードを作成し、あなたが行ったようにあなたがトピックの削除を有効にした場合、delete_topicsチャイルズを監視カフカブローカーで指定されたスレッド（TopicDeletionManager）は、この、この平均値からの削除を処理しますzookeperだけでなく、すべてのカフカレプリカからログを取って、無効な状態にならないようにします。全体のプロセスは、ここで説明されています https://github.com/apache/kafka/blob/0.11.0/core/src/main/scala/kafka/controller/TopicDeletionManager.scala

/** 
* This manages the state machine for topic deletion. 
* 1. TopicCommand 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's ControllerEventThread handles topic deletion. A topic will be ineligible 
* for deletion in the following scenarios - 
    * 3.1 broker hosting one of the replicas for that topic goes down 
    * 3.2 partition reassignment for partitions of that topic is in progress 
* 4. Topic deletion is resumed when - 
* 4.1 broker hosting one of the replicas for that topic is started 
* 4.2 partition reassignment for partitions of that topic completes 
* 5. Every replica for a topic being deleted is in either of the 3 states - 
* 5.1 TopicDeletionStarted Replica enters TopicDeletionStarted phase when onPartitionDeletion is invoked. 
*  This happens when the child change watch for /admin/delete_topics fires on the controller. As part of this state 
*  change, the controller sends StopReplicaRequests to all replicas. It registers a callback for the 
*  StopReplicaResponse when deletePartition=true thereby invoking a callback when a response for delete replica 
*  is received from every replica) 
* 5.2 TopicDeletionSuccessful moves replicas from 
*  TopicDeletionStarted->TopicDeletionSuccessful depending on the error codes in StopReplicaResponse 
* 5.3 TopicDeletionFailed moves replicas from 
*  TopicDeletionStarted->TopicDeletionFailed depending on the error codes in StopReplicaResponse. 
*  In general, if a broker dies and if it hosted replicas for topics being deleted, the controller marks the 
*  respective replicas in TopicDeletionFailed state in the onBrokerFailure callback. The reason is that if a 
*  broker fails before the request is sent and after the replica is in TopicDeletionStarted state, 
*  it is possible that the replica will mistakenly remain in TopicDeletionStarted state and topic deletion 
*  will not be retried when the broker comes back up. 
* 6. A topic is marked successfully deleted only if all replicas are in TopicDeletionSuccessful 
* state. Topic deletion teardown mode deletes all topic state from the controllerContext 
* as well as from zookeeper. This is the only time the /brokers/topics/<topic> path gets deleted. On the other hand, 
* if no replica is in TopicDeletionStarted state and at least one replica is in TopicDeletionFailed state, then 
* it marks the topic for deletion retry. 

飼育係から直接削除するだけでオーケストレーターからの削除を意味します。確かにメタデータを要求するとき、トピックはもはや存在しません（おそらくキャッシュからのものかもしれませんが）ログファイルは削除されません（少なくとも今はそうではありません、ブローカーはログが無効であると検出し、 ）、あなたはブローカーに不一致があるかもしれません（あなたがバランスを取っていれば、多くのことを破ります）。これは、いくつかのブローカーが削除されたと考えている間に、他のブローカーがそれがまだそこにあると考えるだろうということを意味するかもしれません。

現時点ではfom zookeeper（およびブローカからのログ）を削除することは可能ですが、矛盾、無効な状態、ランダムエラーが発生する可能性がありますが、将来のバージョンでは機能しない可能性があります。