2 ms·
I've been seriously considering this move as well but am surprised to see zookeeper mentioned so much. Solr's use of zookeeper is tiny and managing the log fil
by liveoneggs 5y ago
I've been seriously considering this move as well but am surprised to see zookeeper mentioned so much. Solr's use of zookeeper is tiny and managing the log files is something like this:
autopurge.snapRetainCount=5
autopurge.purgeInterval=12
Pretty much set-and-forget (assuming you don't get disk timeouts on zk or network timeouts from solr-to-zk).
- jamesgover 5y ago>> assuming you don’t get disk timeouts on zk or network timeouts from solr-to-zk Unfortunately this is the tricky bit - Zookeeper’s usage of Solr might be small from a disk/network perspective but given it’s used for leader election, any issues with Zookeeper can cascade into much larger problems with Solr. We’ve had a couple rather large scale outages that came about this way. The compounding factor was as it works most of the time it was hard to keep zookeeper expertise and tested scripts. This expertise is getting hard to hire for and the documentation is scarce enough we found it hard to train internally.
- liveoneggs 5y agoI know these outages well ;). Running zk on its own (small) cluster helps a lot. I also nice the zk jvm all the way. Another tip for the desperate who find it -- when solr cloud totally locks up you should look up who is acting as the OVERSEER in zookeeper and focus on restarting that node, possibly with others all down.