Yeah, much as I love SolrCloud (and make most of my living working with it), it does have its complexities.
My rule of thumb is that you really want to consider SolrCloud when you start having to shard or need NRT searching. You trade the complexity of maintaining your own sharding etc. for the complexity of ZooKeeper for the former, and can't do the latter with master/slave, so whatever floats your boat ;) About ZooKeeper: with a system your size, you would absolutely _not_ need any more than three. In fact, if you were willing to accept that your one ZooKeeper going down would prevent updates from happening, you could run with just one. And your ZK machines could be cheap boxes, they don't need all that much processing power. That said, if it's just a matter of plopping in Solr 7x (or whatever) over your existing infrastructure that's been running for years, I really can't say you should move to SolrCloud.... Best, Erick On Sat, Dec 16, 2017 at 9:36 AM, Shawn Heisey <apa...@elyograg.org> wrote: > On 12/15/2017 12:12 PM, David Hastings wrote: >> >> Also the complexity of adding another 3 >> or more machines just to do nothing but ZK stuff was getting out of hand. > > > You can run ZK on the same machines that are running Solr. The only strong > recommendation that I would make is that it should be a completely separate > process, not embedded within Solr. The ZK process is unlikely to need much > of a heap, unless your ZK database is huge. > > It can also be useful to have ZK's data on separate disks from other things > on the machine, but this is not usually necessary. > > Thanks, > Shawn
