[
https://issues.apache.org/jira/browse/KAFKA-1752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14206915#comment-14206915
]
Joe Stein commented on KAFKA-1752:
----------------------------------
[~nehanarkhede] Yes, there are two (similar) cases that I have seen requiring
this (where without it lots of scripting happens):
1) Lets say you have a cluster of 12 nodes, and one goes away (because the
backplane on the VM box died lets say). You don't want to be at 11 nodes but
literally want to move everything from node 6 (say that was the one that went
down) to node 13. Now, I know they could just "in service" the new broker as
node 6 but the reality is a lot of folks use IP address for the broker.id and a
new VM might already be launched (automatically on the VM failure) bringing
online a new node if one fails. In this case they want to replace broker.id
172111255 with 1721112542 (because the new vm for the new broker IP is
172.11.125.42)
2) New hardware is also another scenario. A new server is ordered replacing
some old hardware node. You want to keep your X node cluster running, you add
the new hardware and then want to replace node Y with node X+1 without having
to shut down any brokers (some folks run at pretty peak capacities (granted not
a wonderful scenario but they have to operate like that).
I have not seen a scenario where this would be more than one broker that it
spreads again but if we can support a list instead of one I don't think that
some extra flexibility is detrimental in this case.
> add --replace-broker option
> ---------------------------
>
> Key: KAFKA-1752
> URL: https://issues.apache.org/jira/browse/KAFKA-1752
> Project: Kafka
> Issue Type: Sub-task
> Components: tools
> Reporter: Dmitry Pekar
> Assignee: Dmitry Pekar
> Fix For: 0.8.3
>
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
