Raveebdra, Thank for your reply. Could you please provide more details or share a link explaining how a Solr node can be started without immediately joining the cluster and receiving query traffic?
Get Outlook for iOS<https://aka.ms/o0ukef> ________________________________ From: raveendra.yerraguntla <[email protected]> Sent: Thursday, 24 September 2026 16:58:41 To: Lotfi Mehai <[email protected]>; [email protected] <[email protected]> Subject: Re: SolrCloud 9.10.1: ZooKeeper Upgrade and Node Maintenance Questions THIS EMAIL IS FROM AN UNTRUSTED EMAIL PROVIDER. With the replication factor of more than 1, this is possible and commonly done in high availability applications On Thu Sep 24 20:05:23 UTC 2026, Lotfi Mehai <[email protected]> wrote: Raveedra, Thanks for your input on the first question. Do you have any feedback on the second question? Lotfi ________________________________ From: raveendra.yerraguntla <[email protected]> Sent: Thursday, September 24, 2026 3:33 PM To: [email protected] <[email protected]> Cc: Lotfi Mehai <[email protected]> Subject: Re: SolrCloud 9.10.1: ZooKeeper Upgrade and Node Maintenance Questions THIS EMAIL IS FROM AN UNTRUSTED EMAIL PROVIDER. It’s fine to use rolling upgrade but please refer to the CVE-2026-59969, and please check the TLS certificates and SANs in zoo.cfg. In case of potential issues, normalize the TLS certs with expected SANs before migration On Thu Sep 24 19:13:35 UTC 2026, Lotfi Mehai via users <[email protected]> wrote: I'm currently migrating from Solr 9.10.1 in a leader-follower architecture to SolrCloud 9.10.1. I have the following questions and would appreciate your input and guidance. 1. ZooKeeper upgrade and compatibility We opted for an external ZooKeeper ensemble, as recommended, and currently have ZooKeeper 3.9.4 installed. There is currently a Netty vulnerability, CVE-2026-45674, with a CVSS score of 10. Netty is a transitive dependency of ZooKeeper. I would like to upgrade ZooKeeper to the latest available minor version that addresses the vulnerability. Is it common and supported practice to upgrade to a newer minor version of ZooKeeper while keeping the same Solr version? I also have Java services that use SolrJ to communicate with the SolrCloud cluster and ZooKeeper. My assumption is that backward compatibility is maintained between ZooKeeper minor versions. In other words, a Java service using a newer compatible ZooKeeper client version should be able to communicate with an older ZooKeeper server version (ZooKeeper 3.9.4). I'm considering the following upgrade approach: * Upgrade and deploy the Java services with the newer ZooKeeper client version (solrj-zookeeper-9.10.1.jar + zookeeper-3.9.6.jar`). * Perform a rolling, in-place upgrade of the external ZooKeeper ensemble from ZooKeeper 3.9.4 to 3.9.6. * Keep Solr at version 9.10.1 during the ZooKeeper upgrade. Is this a recommended and supported approach? Is it common practice to perform a live rolling upgrade of a production ZooKeeper ensemble, upgrading one ZooKeeper node at a time while maintaining quorum, or is it recommended to perform the upgrade on a secondary ensemble and then switch over? 2. Temporarily isolating a Solr node for OS patching Is there a supported way to temporarily detach or isolate a Solr node from the SolrCloud cluster while keeping the Solr service running? During OS patching, I would like to bring the node back up, keep it out of production query traffic, perform health checks and warm up its caches, and then allow it to rejoin production traffic only after validation is complete. What is the recommended SolrCloud approach for this type of maintenance and controlled re-entry into the cluster? Lotfi Mehai
