I was considering the process of a Solr upgrade to a SolrCloud cluster within a minor version (e.g. 8.3 -> 8.4).
A concern I have is the implication of new Lucene index formats. Lucene 8.4 bumped the Codec version because of postings being written differently to be more SIMD friendly -- https://issues.apache.org/jira/browse/LUCENE-9027 Lucene 8.4 will read an index created with Lucene 8.3 -- great; but Lucene 8.3 obviously can't read an index created with Lucene 8.4. I'm not picking on this specific JIRA/change; it could be many others. There's another coming in 8.6. We've got some documentation on the upgrade process: https://github.com/apache/lucene-solr/blob/master/solr/solr-ref-guide/src/upgrading-a-solr-cluster.adoc The instructions describe a rolling upgrading of each node one at a time. Makes sense. However, it's possible for a shard on an already upgraded node to become leader, have some documents written to it, and then a replica on a non-upgraded node might end up replicating segments from the leader. This is possible with all replica types, though I think more likely with TLOG & PULL. I am not sure if there are any protections for this (e.g. in replication handler / index fetcher); there should be. I think that SolrCloud should prevent a replica from becoming a leader if there exists another replica (for the same shard) that has a lower Solr version. I can think of two work-arounds: (A) shut down the whole cluster to do the upgrade (forced down time) (B) initiate read-only status for all collections https://github.com/apache/lucene-solr/blob/master/solr/solr-ref-guide/src/collection-management.adoc#L258 and also be careful not to create new collections during this time. Then do the rolling upgrade as described in the docs above, and then remove the read-only status. ~ David Smiley Apache Lucene/Solr Search Developer http://www.linkedin.com/in/davidwsmiley
