Trying to add a new broker to the Kafka cluster and decommission the
existing broker. Using the reassignment-partitions script, the partitions
are migrated successfully to the new broker. But the consumer offsets are
not migrating from existing broker to the new broker (Consumer offsets are
stored
broker is decommissioned which will then lead to us figuring
out an ideal partition reassignment and executing it until the decommissioned
broker owns nothing?
Or were you thinking about this differently?
> add --replace-broker option
> ---
>
>
[
https://issues.apache.org/jira/browse/KAFKA-1752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on KAFKA-1752 stopped by Dmitry Pekar.
---
> add --replace-broker opt
[
https://issues.apache.org/jira/browse/KAFKA-1752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Pekar resolved KAFKA-1752.
-
Resolution: Won't Fix
> add --replace-broke
eded any more. Instead of this
KAFKA-1792 should be implemented.
Closing this as not required to implement.
> add --replace-broker option
> ---
>
> Key: KAFKA-1752
> URL: https://issues.apache.org/jira/browse/KAFKA-1752
&g
add --replace-broker option
> ---
>
> Key: KAFKA-1752
> URL: https://issues.apache.org/jira/browse/KAFKA-1752
> Project: Kafka
> Issue Type: Sub-task
> Components: tools
>
ution.
The scope of this issue is:
- design an algorithm matching the above requirements;
- implement this algorithm and unit tests;
- test it manually using different initial assignments;)
Summary: add --replace-broker option (was: change behavior of
--generate to produce assignment config
rtition 0 replica from broker 0 or 1 leaving it without data?
- leave broker 2 without data?
- change the replication factor of partition 0?
- raise an error that there is no data for broker 2 to assign?
> add --replace-broker option
> ---
>
>
r replica placement strategy.
> add --replace-broker option
> ---
>
> Key: KAFKA-1752
> URL: https://issues.apache.org/jira/browse/KAFKA-1752
> Project: Kafka
> Issue Type: Sub-task
> Compon
That, probably, could be implemented. But wouldn't it create
unpredictable and unmanageable (from user's point of view) replica
redistribution? Also should we consider using a strategy with optimal (minimal
number) moving of replicas between brokers?
>
d be implemented. But wouldn't it create
unpredictable and unmanageable (from user's point of view) replica
redistribution? Also should we consider using a strategy with optimal (minimal
number) moving of replicas between brokers?
> add --repl
oker (and transfer some load to it)
and --decommission-broker (and transfer its load somewhere)?
This makes sense to me.
> add --replace-broker option
> ---
>
> Key: KAFKA-1752
> URL: https://issues.apache.org/jir
. If KAFKA-1753
--decommission-broker ID has added to it a strategy to figure out where to
place the partitions by evenly transferring that broker's partitions then that
solves this ticket at the same time too, agreed.
> add --replace-b
he 2 scenarios you mentioned above.
However, shouldn't adding one or more new brokers just evenly transfer existing
partitions off of the cluster to the new nodes? I actually don't think the
--replace-broker --broker-list is intuitive. All users want is to
add new brokers and
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/
king this option a little, do we need
--replace-broker if we have a way to decommission a broker? Even when we enable
automatic node assignments, can you give an example of a case where we need
--replace-broker?
> add --replace-broker option
> ---
>
>
[
https://issues.apache.org/jira/browse/KAFKA-1752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14206524#comment-14206524
]
Joe Stein commented on KAFKA-1752:
--
I like the approach
--replace-broker 1 --br
s us to specify several brokers, which may be unavoidable in some replace
scenarios (could provide examples, if required) and in "delete broker" scenario
(i.e. in cluster 0,1,2 "delete 1" is exactly the same as "replace 1 => 0,2")
So the command will look like:
n.
> add --replace-broker option
> ---
>
> Key: KAFKA-1752
> URL: https://issues.apache.org/jira/browse/KAFKA-1752
> Project: Kafka
> Issue Type: Sub-task
> Components: tools
&g
6 AM:
--
+1 to having this feature.
Maybe a more readable option will be:
--replace-broker 1 --with-broker 2
(not a committer, so my opinion is not binding)
was (Author: gwenshap):
+1 to having this feature.
Maybe a more readable option will be:
--replace-broker 1 --with-broker 2
> add --
more readable option will be:
--replace-broker 1 --with-broker 2
> add --replace-broker option
> ---
>
> Key: KAFKA-1752
> URL: https://issues.apache.org/jira/browse/KAFKA-1752
> Project: Kafka
>
add --replace-broker CLI option. Value of option is comma-separated pair of
broker ids (src,dst).
Example:
--replace-broker 1,2
means replace broker[id=1] with broker[id=2] in cluster.
Please, negotiate.
> add --replace-broker option
> ---
>
>
[
https://issues.apache.org/jira/browse/KAFKA-1752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Neha Narkhede updated KAFKA-1752:
-
Reviewer: Neha Narkhede
> add --replace-broker opt
[
https://issues.apache.org/jira/browse/KAFKA-1752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on KAFKA-1752 started by Dmitry Pekar.
---
> add --replace-broker opt
[
https://issues.apache.org/jira/browse/KAFKA-1752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Pekar reassigned KAFKA-1752:
---
Assignee: Dmitry Pekar
> add --replace-broker opt
Dmitry Pekar created KAFKA-1752:
---
Summary: add --replace-broker option
Key: KAFKA-1752
URL: https://issues.apache.org/jira/browse/KAFKA-1752
Project: Kafka
Issue Type: Sub-task
26 matches
Mail list logo
