When a broker is not in a topic's ISR, will it try to catch up to go back to ISR itself? Or do we have to restart it?
We can increase replica.lag.time.max.ms and replica.lag.max.messages to let brokers stay longer in ISR. Is that good practice? Still this is related to the first questions. We want to know what happens after a broker falls out of ISR and what we should do. Thanks. Regards,
That's right. You shouldn't need to restart the whole cluster for a broker to rejoin ISR. Do you see many ZK session expirations in the brokers (search for "(Expired)"? If so, you may need to tune the GC on the broker.
Jun On Mon, Aug 26, 2013 at 7:11 AM, Yu, Libo <[EMAIL PROTECTED]> wrote:
1. What is the best practice to set replica.lag.time.max.ms & replica.lag.max.messages ? As long as possible or something else ?
2. If the broker exceeds one of these 2 configurations, how should we do to bring the broker back to ISR ? Will controller automatic cover this to catch broker up, the only thing we need to do is waiting for the broker back ?
Thanks. On Mon, Aug 26, 2013 at 11:15 PM, Jun Rao <[EMAIL PROTECTED]> wrote:
Look for jmx beans under kafka.server. You will see ???MaxLag and ???MinFetchRate. In the normal case, when a broker fails, the controller will drop the failed broker out of ISR during leader election. So, the value of replica.lag.time.max.ms doesn't matter. This value only matters when the controller's decision is delayed somehow. In this case, having a large replica.lag.time.max.ms may delay the committing of a message.
Jun On Tue, Aug 27, 2013 at 6:37 AM, Yu, Libo <[EMAIL PROTECTED]> wrote:
Apache Lucene, Apache Solr and all other Apache Software Foundation projects and their respective logos are trademarks of the Apache Software Foundation.
Elasticsearch, Kibana, Logstash, and Beats are trademarks of Elasticsearch BV, registered in the U.S. and in other countries. This site and Sematext Group is in no way affiliated with Elasticsearch BV.
Service operated by Sematext