[
https://issues.apache.org/jira/browse/SOLR-17879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18017820#comment-18017820
]
David Smiley commented on SOLR-17879:
-------------------------------------
I'm thinking that this restriction would be more useful if it applied to the
minor version as well. Even without this proposal, it's *already* the case
that a minor version may incorporate a Lucene minor version bump, which in turn
introduces a new codec (index format). A rolling downgrade is not possible.
So let's prevent this at the Solr layer as well, ehh? It would be more user
friendly for a codec change -- stopping a server when it starts with a clear
error instead of a delayed more difficult error. It would give us the ability
to introduce a cluster coordination / ZK change at a minor release in a safe
way.
WDYT [~houston]?
> A SolrCloud node should fail to start if it's major version is smaller than
> the cluster
> ---------------------------------------------------------------------------------------
>
> Key: SOLR-17879
> URL: https://issues.apache.org/jira/browse/SOLR-17879
> Project: Solr
> Issue Type: Improvement
> Components: SolrCloud
> Reporter: David Smiley
> Priority: Major
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> If there's a "Solr 10 cluster" (meaning, a cluster in which all live_nodes
> express Solr 10 via SOLR-17620), and the current node that which is about to
> join the cluster is Solr 9, then the current node should fail to start. This
> should be enforced for a difference in major versions. This is not an
> enforcement of the inverse -- a Solr 10 node +may+ joint a Solr 9 cluster,
> and thus a rolling upgrade is not prevented.
> Solr versions >= 9.10 can enforce this but already released Solr versions
> (like 9.9) will not be able to do so.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
