[jira] [Comment Edited] (SOLR-14708) Backward-Compatible Replication

["Marcus Eagan (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/SOLR-14708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17172947#comment-17172947 ] 

Marcus Eagan edited comment on SOLR-14708 at 8/7/20, 7:18 AM:
--------------------------------------------------------------

Also, master/slave is not very documented as well. It is straightforward, but annoying to work with, for sure because there is little documentation.


was (Author: marcussorealheis):
Also, master/slave is not very documented as well. It is straightforward, but annoying to work with, for sure.

> Backward-Compatible Replication
> -------------------------------
>
>                 Key: SOLR-14708
>                 URL: https://issues.apache.org/jira/browse/SOLR-14708
>             Project: Solr
>          Issue Type: Bug
>      Security Level: Public(Default Security Level. Issues are Public) 
>          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-unsubscribe@lucene.apache.org
For additional commands, e-mail: issues-help@lucene.apache.org