There is "replica.lag.max.messages" (defaults to 4k) and
"" (defaults to 10s). If a replica is behind
the leader by either that many messages or hasn't sent any fetch
requests within the lag config, then it falls out of ISR.

However, as mentioned earlier it is best to avoid a cross-DC
replication set up. You should set the above configs to be reasonable
values (the defaults should be reasonable, but it depends on your
volume) and if you see replicas going out of ISR then address the
underlying issue(s) - e.g., depending on what the issue is it could be
enough to increase the number of replica fetcher threads. Increasing
the replica message and time lag may help reduce ISR churns but it
does not address the issue (which is replicas being unable to keep
On Sat, Jun 29, 2013 at 10:47 AM, Yu, Libo <[EMAIL PROTECTED]> wrote:

NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB