[
https://issues.apache.org/jira/browse/SOLR-14708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17173488#comment-17173488
]
Tomas Eduardo Fernandez Lobbe commented on SOLR-14708:
------------------------------------------------------
I was able to verify the case B manually following these steps:
1) Go to the directory with the patched 8.x branch
2) edit {{server/solr/configsets/_default/conf/solrconfig.xml}}, remove all
entries of {{class="solr.FastLRUCache"}} and {{class="solr.LRUCache"}} (remove
the attribute completely, in 8.7 the default is already {{CaffeineCache)}}
3) Start Solr like this: {{bin/solr start -e cloud}}
4) When prompted, start Solr with a single node, create the collection
{{gettingstarted}} with one shard and one replica
5) Post some documents with {{bin/post -c gettingstarted example/exampledocs}}
(Note that this prints some errors that seems to be related to the extract
request handler? something to followup with)
6) Go to the directory with Solr master
7) Start Solr with {{bin/solr start -z localhost:9983 -p 8984}}
// You can validate here that the new node joins the cluster by looking at the
UI
8) Run this command to add a replica:
{{[http://localhost:8983/solr/admin/collections?action=addreplica&collection=gettingstarted&shard=shard1]}}
9) Check that the new replica is in the new node, it's active and has data (I
ran this:
{{[http://localhost:8984/solr/gettingstarted_shard1_replica_n3/select?q=*:*&distrib=false]}}).
If this happens, it means the replication was successful. I also looked at the
logs for errors but everything seems OK
> 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
