[
https://issues.apache.org/jira/browse/SOLR-14708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17210455#comment-17210455
]
Cassandra Targett edited comment on SOLR-14708 at 10/8/20, 9:06 PM:
--------------------------------------------------------------------
[~tflobbe], [~marcussorealheis] - this change didn't get added to the Upgrade
Notes for 8.7, so I'm working on that now. 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?
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".
was (Author: ctargett):
[~tflobbe], [~marcussorealheis] - this change didn't get added to the Upgrade
Notes for 8.7, so I'm working on that now. If I understand this work correctly,
there should be no compatibility issues for someone moving from 8.6 to 8.7 if
they do not change their solrconfig.xml, is that correct?
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".
> 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: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
