[
https://issues.apache.org/jira/browse/KAFKA-1546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14384734#comment-14384734
]
Aditya Auradkar commented on KAFKA-1546:
----------------------------------------
[~junrao] I found references to this config in a few places. Do I have to make
changes to "configuration.html" for 0.8.3?
$ grep -r "replica.lag.max.messages" *
configuration.html: <td>replica.lag.max.messages</td>
design.html:We refer to nodes satisfying these two conditions as being "in
sync" to avoid the vagueness of "alive" or "failed". The leader keeps track of
the set of "in sync" nodes. If a follower dies, gets stuck, or falls behind,
the leader will remove it from the list of in sync replicas. The definition of,
how far behind is too far, is controlled by the replica.lag.max.messages
configuration and the definition of a stuck replica is controlled by the
replica.lag.time.max.ms configuration.
ops.html:replica.lag.max.messages=4000
ops.html: <td>< replica.lag.max.messages</td>
ops.html: <td>< replica.lag.max.messages</td>
> Automate replica lag tuning
> ---------------------------
>
> Key: KAFKA-1546
> URL: https://issues.apache.org/jira/browse/KAFKA-1546
> Project: Kafka
> Issue Type: Improvement
> Components: replication
> Affects Versions: 0.8.0, 0.8.1, 0.8.1.1
> Reporter: Neha Narkhede
> Assignee: Aditya Auradkar
> Labels: newbie++
> Fix For: 0.8.3
>
> Attachments: KAFKA-1546.patch, KAFKA-1546_2015-03-11_18:48:09.patch,
> KAFKA-1546_2015-03-12_13:42:01.patch, KAFKA-1546_2015-03-16_11:31:39.patch,
> KAFKA-1546_2015-03-17_14:46:10.patch, KAFKA-1546_2015-03-25_13:27:40.patch,
> KAFKA-1546_2015-03-26_17:44:08.patch, KAFKA-1546_2015-03-27_11:57:56.patch
>
>
> Currently, there is no good way to tune the replica lag configs to
> automatically account for high and low volume topics on the same cluster.
> For the low-volume topic it will take a very long time to detect a lagging
> replica, and for the high-volume topic it will have false-positives.
> One approach to making this easier would be to have the configuration
> be something like replica.lag.max.ms and translate this into a number
> of messages dynamically based on the throughput of the partition.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
