On 2022/03/13 22:22:48 Shawn Heisey wrote: > Zookeeper has fairly low system requirements compared to Solr, so using > a third machine with lower specs to just run the tie-breaker ZK is a > good way to go. > > Note that you'll only have full redundancy at the client level with that > setup if your client is ZK-aware. The only Solr client I know about > that's ZK aware is the Java client, which is part of Solr itself as well > as being a standalone client.
Thank you for bringing this potential issue to my attention. By "standalone client", do you mean that I could use SolrJ on a separate server where no Solr instance is running? i.e. use the client to remotely connect to SolrCloud. By the way, the most popular Python client, pysolr, seems to support SolrCloud mode. [1] > For full redundancy with HTTP-only clients you'll need a virtual IP > address that can be shared among the servers, and have a load balancer > listening on the virtual IP. Setting that up is done with software > other than Solr and ZK, so it's not on-topic for this mailing list. > Depending on the capabilities of the third server, it could be the > primary for load-balancing as well as the third machine for ZK. > That's what I would do with limited resources. I think I will stick to ZooKeeper-aware clients if I choose to go the SolrCloud route. Using the SolrJ "CloudSolrClient" looks like a much simpler solution than setting up all the infrastructure required for achieving high availability with HTTP-only clients. [1]: https://github.com/django-haystack/pysolr
