You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@kafka.apache.org by "Neha Narkhede (JIRA)" <ji...@apache.org> on 2013/03/20 17:03:15 UTC

[jira] [Commented] (KAFKA-155) Support graceful Decommissioning of Broker

    [ https://issues.apache.org/jira/browse/KAFKA-155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13607766#comment-13607766 ] 

Neha Narkhede commented on KAFKA-155:
-------------------------------------

ShutdownBroker admin command does not completely achieve this. It merely moves the leader from that broker and then shuts the broker down. But now, some of the partitions could be under replicated. What really solves the problem is preferred replica election admin command. This allows you to add new brokers to an existing cluster, move some partition off of the brokers to be decommissioned and then shutdown the broker by killing it.
                
> Support graceful Decommissioning of Broker
> ------------------------------------------
>
>                 Key: KAFKA-155
>                 URL: https://issues.apache.org/jira/browse/KAFKA-155
>             Project: Kafka
>          Issue Type: Improvement
>            Reporter: Sharad Agarwal
>             Fix For: 0.8
>
>
> There should be a graceful way of decommissioning the broker so that there is absolutely 0 data loss. Decommissioning is not necessarily related to replication (Kafka-50).
> There should be a way to get the broker out of the cluster only from the produce side. Consumers should be able to continue keep pulling data. When the administrator is sure that all data has been consumed by consumers, broker node can be removed permanently.
> Same would be useful for rolling upgrades without any message loss.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira