> Yeah, it took me a few tries to get it all straight in my head. Thanks Erick for your fast answer!
> The only "problem" with running ZK on the same node as Solr is that if the > node goes down, it takes _both_ zookeeper and Solr with it. If running > the "embedded zookeeper", then you can't even bounce the Solr server without > taking down the ZK node. Solr will run fine even with embedded ZK, > you just have to be very careful when you take the node up or down. Yes, but what happens when a Zookeeper node goes down if I have three nodes? As a Solr node could go down, even a Zookeper one could go down, so this _needs_ to be an expected issue in a highly available infrastructure, doesn't it? > Bottom line: It's just easier, from an administrative standpoint, to > run Zookeeper > as an external process. That way, you can freely bounce your Solr nodes > without falling below quorum. Whether or not it shares the same machine as a > running instance of Solr is up to you. > You absolutely _do_ want to > 1> have at least one replica for each and every shard on a different box > 2> have each Zookeeper running on a separate box. But doing so I need 6 nodes, am I wrong? > That way, if any single box dies you have a complete collection available and > a quorum of ZK nodes present. How many more machines you have and > how you distribute your collections amongst them is up to you. If I have three ZK nodes I will have the quorum even with two available nodes, right?
