Page History

...

We could store the pending replicas in a single Znode per cluster, rather than putting them beside the ISR replicas in /brokers/topics/[topic]/partitions/[partitionId]/state.  However, this Znode might become very large, which could lead to us running into maximum znode size problems.  This is an existing scalability limitation which we would like to solve.

Another reason for storing the targetReplicas state reassigning replicas state in the ISR state /brokers/topics/[topic] Znode is that this state belongs in the LeaderAndIsrRequestthere, next to the replicaSet.  By making it clear which replicas are pending and which are existing, we pave the way for future improvements in reassignment.  For example, we will be able to distinguish between reassignment traffic and non-reassignment traffic for quota purposes, and provide better metrics.

...