On 5/2/2018 11:44 AM, Adam Blank wrote: > Shawn - Sorry if I mixed up terminology, but by standalone I meant having a > single Zk instead of a Zk ensemble. So I would reconfigure the remaining > Zk and Solr node to only use that single Zk. To your point about the > config data being stored in Zk, I'm thinking that should be alright in this > case since the remaining Zk should already have that data stored?
If the goal is to avoid manual intervention in the face of failure, the scenario you've described does not meet that goal. You would have to reconfigure and restart services. Adding another machine for a third ZK would eliminate the need to do that. Andor's assertion that the machine should have similar horsepower to the others would only apply if the only thing those machines are running is ZK. If you've got two beefy machines doing both Solr and ZK and a third machine doing only ZK, the third machine does not need as much horsepower. It should certainly not be slow, but it's not going to need the same level of storage and memory that the other two will. A lot of the CPU horsepower on the two beefy machines would be used for Solr, so the third machine probably doesn't need as much CPU either. For an install where you're trying to get by with two machines, it is highly unlikely that SolrCloud would put much of a load on ZK. Most of what SolrCloud writes to ZK is cluster state changes -- machines going up/down, collections created/deleted, etc. When a SolrCloud cluster is stable, there will be very little written to ZK. Earlier I said that when ZK loses quorum, SolrCloud will go read-only. This is true, but it does NOT mean that index updates go through ZK. They do not. SolrCloud switches to read-only when ZK quorum goes away to protect itself from split-brain problems. Thanks, Shawn
