...
We will add a new field to LeaderAndIsrRequest named PendingReplicasTargetReplicas. This field will contain the replicas which will exist once the partition reassignment is complete.
| Code Block | ||
|---|---|---|
| ||
diff --git a/clients/src/main/resources/common/message/LeaderAndIsrRequest.json b/clients/src/main/resources/common/message/LeaderAndIsrRequest.json index b8988351c..d45727078 100644 --- a/clients/src/main/resources/common/message/LeaderAndIsrRequest.json +++ b/clients/src/main/resources/common/message/LeaderAndIsrRequest.json @@ -20,6 +20,8 @@ // Version 1 adds IsNew. // // Version 2 adds broker epoch and reorganizes the partitions by topic. + // + // Version 3 adds PendingReplicasTargetReplicas. "validVersions": "0-3", "fields": [ { "name": "ControllerId", "type": "int32", "versions": "0+", @@ -48,6 +50,8 @@ "about": "The ZooKeeper version." }, { "name": "Replicas", "type": "[]int32", "versions": "0+", "about": "The replica IDs." }, + { "name": "PendingReplicasTargetReplicas", "type": "[]int32", "versions": "3+", "nullableVersions": "0+", + "about": "The replica IDs that we are reassigning the partition to, or null if the partition is not being reassigned." }, { "name": "IsNew", "type": "bool", "versions": "1+", "default": "false", "ignorable": true, "about": "Whether the replica should have existed on the broker or not." } ]} |
...
Another reason for storing the pendingReplicas state targetReplicas state in the ISR state ZNode is that this state belongs in the LeaderAndIsrRequest. 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.
...