[
https://issues.apache.org/jira/browse/SOLR-14708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17210498#comment-17210498
]
Tomas Eduardo Fernandez Lobbe commented on SOLR-14708:
------------------------------------------------------
bq. If I understand this work correctly, there should be no compatibility
issues for someone moving from 8.x to 8.7 if they do not change their
solrconfig.xml, is that correct?
Right, that was the intent.
bq. I'm wondering, though, that we should tell them to update their
solrconfig.xml files manually because if they don't, they will have issues
upgrading to 9.0? I mean, at some point they will need to excise the old terms
we're trying to get rid of or else they'll keep carrying it along forever. The
message I'm thinking would be something like "go ahead and do your rolling
upgrade, but you should fix your configs after at a convenient time".
The thing is that they can't upgrade their configuration until all the nodes
are at least in 8.7, because 8.6 won't know how to read those conf changes.
There are some [upgrade notes in
9|https://github.com/apache/lucene-solr/pull/1718/files] (which I'm noticing
don't say anything about solrconfig, so they may need some improvement). The
point when someone HAS to make changes is when upgrading to 9 (I believe only
in metrics). Note that Solr 9 can still read the old nomenclature in both,
configs and parameters.
> Backward-Compatible Replication
> -------------------------------
>
> Key: SOLR-14708
> URL: https://issues.apache.org/jira/browse/SOLR-14708
> Project: Solr
> Issue Type: Bug
> Components: SolrCloud
> Reporter: Marcus Eagan
> Priority: Critical
>
> In [SOLR-14702|https://issues.apache.org/jira/browse/SOLR-14702] I proposed
> that we remove master/slave terminology from the Solr codebase. Now that's
> complete, we need to ensure it is backward compatible to support rolling
> upgrades from 8.7.x to 9.x because we really ought not to make it harder to
> upgrade Solr.
> Tomas offered a helpful path in a now abandoned PR:
> {quote}One way to get back compatibility and rolling upgrades could be to
> make 9.x code be able to read previous formats, but write new format, and
> make 8.x (since 8.7) read new and old, but write old? Anyone wanting to do a
> rolling upgrade to 9 would have to be on at least 8.7. Rolling upgrades to
> 8.7 would still work.
> All the code other than the requests/responses could be changed in 8_x
> branch, in addition to master.
> {quote}
> The approach that we will take is to add a ternary operator in 9_X to accept
> parameter values for the legacy verbiage, or leader/follower, but only write
> leader/follower. We need to then make 8_x work in the inverse way. The burden
> here is not on that proposal or on the code in my view. Instead, the burden
> is on the test plan.
> If anyone has any guidance please share but here are my thoughts:
> Case A:
> Test the case where a user is running a standalone cluster in 8 with three
> nodes but then updates one of the nodes.
> Case B:
> Test the case where a user is running a mixed cluster standalone cluster, and
> the leader node is forced to fail and then is brought back.
> Case C:
> A SolrCloud cluster that has a mix of 8 and 9 nodes goes down during a
> rolling upgrade and a follower needs to become leader.
> I know haven't listed all possible scenarios or everything that could happen.
> Please let me know if you have thoughts or guidance on how best to accomplish
> this work.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
