kafka-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Neha Narkhede (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (KAFKA-155) Support graceful Decommissioning of Broker
Date Wed, 20 Mar 2013 16:03:15 GMT

    [ 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

View raw message