[
https://issues.apache.org/jira/browse/KAFKA-6794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16712629#comment-16712629
]
Viktor Somogyi commented on KAFKA-6794:
---------------------------------------
I think this change doesn't need a KIP for now, so I'm collected the algorithm
and some examples here, [~hachikuji] please have a look at it.
h2. Calculating A Reassignment Step
For calculating a reassignment step, always the final target replica (FTR) set
and the current replica (CR) set is used.
# Calculate the replicas to be dropped (DR):
# Calculate n = size(FTR) - size(CR)
## Filter those replicas from CR which are not in FTR, this is the excess
replica (ER) set
## Sort the ER set in an order where the leader is the last (this will ensure
that it will be selected only when needed).
## Take the first n replicas of ER, that will be the set of dropped replicas
# Calculate the new replica (NR) to be added by selecting the first replica
from FTR that is not in CR
# Create the target replica (TR) set: CR + NR - DR
# If this is the last step, then order the replicas as specified by FTR. This
means that the last step is always equals to FTR
h2. Performing A Reassignment Step
# Wait until CR is entirely in ISR. This will make sure that we're starting
off with a solid base for reassignment.
# Calculate the next reassignment step as described above based on the
reassignment context.
# Wait until all brokers in the target replicas (TR) of the reassignment step
are alive. This will make sure that reassignment starts only when the target
brokers can perform the actual reassignment step.
# If we have new replicas in ISR from the previous step, change the states' of
those to OnlineReplica
# Update CR in Zookeeper with TR: with this the DR set will be drop and NR set
will be added.
# Send LeaderAndIsr request to all replicas in CR + NR so they would be
notified of the Zookeeper events.
# Start new replicas in NR by moving them to NewReplica state.
# Set CR to TR in memory.
# Send LeaderAndIsr request with a potential new leader (if current leader not
in TR) and a new CR (using TR) and same ISR to every broker in TR
# Replicas in DR -> Offline (force those replicas out of ISR)
# Replicas in DR -> NonExistentReplica (force those replicas to be deleted)
# Update the /admin/reassign_partitions path in ZK to remove this partition.
# After electing leader, the replicas and ISR information changes, so resend
the update metadata request to every broker
h2. Example
The following code block shows how a transition happens from (0, 1, 2) into (3,
4, 5) where the initial leader is 0.
{noformat}
(0, 1, 2) // starting assignment
|
(0, 1, 2, 3) // +3
|
(0, 2, 3, 4) // -1 +4
|
(0, 3, 4, 5) // -2 +5
|
(3, 4, 5) // -0, new leader (3) is elected, requested order is matched,
reassignment finished
{noformat}
Let's take a closer look at the third step above:
{noformat}
FTR = (3, 4, 5)
CR = (0, 1, 2, 3)
n = size(FTR) - size(CR) // 1
ER = CR - FTR // (0, 1, 2)
ER = order(ER) // (1, 2, 0)
DR = takeFirst(ER, n) // (1)
NR = first(FTR - CR) // 4
TR = CR + NR - DR // (0, 2, 3, 4)
{noformat}
> Support for incremental replica reassignment
> --------------------------------------------
>
> Key: KAFKA-6794
> URL: https://issues.apache.org/jira/browse/KAFKA-6794
> Project: Kafka
> Issue Type: Improvement
> Reporter: Jason Gustafson
> Assignee: Viktor Somogyi
> Priority: Major
>
> Say you have a replication factor of 4 and you trigger a reassignment which
> moves all replicas to new brokers. Now 8 replicas are fetching at the same
> time which means you need to account for 8 times the current producer load
> plus the catch-up replication. To make matters worse, the replicas won't all
> become in-sync at the same time; in the worst case, you could have 7 replicas
> in-sync while one is still catching up. Currently, the old replicas won't be
> disabled until all new replicas are in-sync. This makes configuring the
> throttle tricky since ISR traffic is not subject to it.
> Rather than trying to bring all 4 new replicas online at the same time, a
> friendlier approach would be to do it incrementally: bring one replica
> online, bring it in-sync, then remove one of the old replicas. Repeat until
> all replicas have been changed. This would reduce the impact of a
> reassignment and make configuring the throttle easier at the cost of a slower
> overall reassignment.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
