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

Tomas Eduardo Fernandez Lobbe commented on SOLR-14708:
------------------------------------------------------

bq. The caching issue depends on the configset, it seems
Created SOLR-14723
bq. Note that this prints some errors that seems to be related to the extract 
request handler? something to followup with
This is because SOLR-13978 removed the extracting request handler from the 
default configset. Maybe we want to do something about it. The techproducts 
configset does include the extracting request handler still, so I guess it 
shouldn't happen there. I think this is OK. Maybe we can improve the post tool 
to not assume the presence of the extracting handler (specially since it's 
being deprecated) or improve on the error handling.



> 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-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

Reply via email to