There’s a fundamental downside of embedded zk or putting zk on the same node as Solr. When there are many queries running, a Solr replica gets overloaded and it starts to affect the node itself (sometimes you can’t even ssh into the node when Solr is too busy), it also affects the Zk on the same node, which can cause a chain of downed solr replicas and zk nodes, reducing the overall availability of the cluster.
When you need a high read high write cluster, it’s better to put zookeeper on its own machines I think. -ufuk yilmaz > On 23 Nov 2023, at 00:25, Jan Høydahl <jan....@cominvent.com> wrote: > > I think there is a product that speaks ZK api but stores everything in etcd :) > > Also, you may want to check out > https://cwiki.apache.org/confluence/display/SOLR/SIP-18%3A+A+Solr+Kubernetes+Module+for+native+integration > , an initiative that will let you use ConfigMaps for configSet files etc. > I.e. somewhat more cloud native. And > https://cwiki.apache.org/confluence/display/SOLR/SIP-14+Embedded+Zookeeper, > if it gains traction, will embed ZK in Solr processes, making it an > implementation detail that the users dont need to manage separately. > > Jan > >> 22. nov. 2023 kl. 14:30 skrev matthew sporleder <msporle...@gmail.com>: >> >> It's annoying that zookeeper is a hard dependency when etcd is just >> sitting there and all of the stuff in zk could easily fit into >> ConfigMaps. >
