THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
| Table of Contents |
|---|
Status
Current state: Draft Under Discussion
Discussion thread:
JIRA:
| Jira | ||||||
|---|---|---|---|---|---|---|
|
...
| Config name | Type | Default | Valid values | Importance | Dynamic update mode |
|---|---|---|---|---|---|
| leader.reassignment.throttled.rate | Long | Long.MAX_VALUE | [1,...] | medium | per-broker |
| follower.reassignment.throttled.rate | Long | Long.MAX_VALUE | [1,...] | medium | per-broker |
It is useful to add this feature on both leader and follower side as throttling only on the leader for instance make it more complicated to calculate the throughput limit on the follower side. For instance we may have 2 reassigning partitions with the overall limit of 10MB/s configured and that would mean 20MB/s used bandwidth on a broker which is replicating from those partitions. But since replicas can scale up the thousands on a single broker, the complexity of calculating the resulted follower reassignment would increase proportionally.
Behavior-wise they'd throttle the addingReplicas of the LeaderAndIsrRequest during reassignment. Also leader.replication.throttled.replicas and follower.replication.throttled.replicas wouldn't be applied to these replicas as long as they're not in ISR. Once they enter it, they'd be allowed to have the replication bandwidth.
...