[
https://issues.apache.org/jira/browse/SOLR-14708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17173473#comment-17173473
]
Tomas Eduardo Fernandez Lobbe commented on SOLR-14708:
------------------------------------------------------
I manually did test case A like this:
1) Checked out master
2) Ran {{ant clean compile && cd solr && ant server}}
3) Updated {{example/techproducts/solr/techproducts/conf/solrconfig.xml}} by
adding:
{code:xml}
<requestHandler name="/replication" class="solr.ReplicationHandler">
<lst name="follower">
<str name="leaderUrl">http://localhost:8983/solr/techproducts</str>
<str name="pollInterval">00:00:10</str>
</lst>
</requestHandler>
{code}
4) Started Solr with: {{bin/solr start -e techproducts -p 8984}}
5) Stopped Solr with {{bin/solr stop -all}}
6) Removed the data with {{rm -Rf example/techproducts/solr/techproducts/data}}
7) Started Solr again with: {{bin/solr start -e techproducts -p 8984}}. This
time it won't re-create the core and won't add data (I had to do this because I
don't know if there is a way to start the example without posting documents,
maybe there is)
8) On a separate directory: checkout the branch from [the
PR|https://github.com/apache/lucene-solr/pull/1719]
9) Ran {{ant clean compile && cd solr && ant server}}
10) Add this code to
{{example/techproducts/solr/techproducts/conf/solrconfig.xml}}:
{code:xml}
<requestHandler name="/replication" class="solr.ReplicationHandler">
<lst name="leader">
<str name="replicateAfter">commit</str>
<str name="backupAfter">commit</str>
</lst>
</requestHandler>
{code}
11) Verified that replication happened:
* I can query the data on the 9.x version (follower)
* No errors in the logs (other than "invalid leader" in the follower before
the leader was started, which is expected)
* Right commands in the logs (using {{leader}} instead of {{master}}, etc)
{quote}Admin UI doesn't work either
{quote}
Could you be more specific? did it not start? I was able to use the UI, and I
checked the browser console for errors but I couldn't find any. UI in 8.x is
now showing "leader" and "follower" as expected.
If I do a query like:
{{[http://localhost:8983/solr/techproducts/replication?command=details]}} I
also see the expected output in 8.x (using legacy nomenclature):
{noformat}
{
"responseHeader":{
"status":0,
"QTime":0},
"status":"OK",
"details":{
"indexSize":"25.65 KB",
"indexPath":"/Users/tflobbe/Documents/workspace/lucene-solr-github-tflobbe/solr/example/techproducts/solr/techproducts/data/index/",
"commits":[[
"indexVersion",1596834098600,
"generation",2,
"filelist",["_0.fdm",
"_0.fdt",
"_0.fdx",
"_0.fnm",
"_0.kdd",
"_0.kdi",
"_0.kdm",
"_0.nvd",
"_0.nvm",
"_0.si",
"_0.tvd",
"_0.tvm",
"_0.tvx",
"_0_Lucene80_0.dvd",
"_0_Lucene80_0.dvm",
"_0_Lucene84_0.doc",
"_0_Lucene84_0.pay",
"_0_Lucene84_0.pos",
"_0_Lucene84_0.tim",
"_0_Lucene84_0.tip",
"_0_Lucene84_0.tmd",
"segments_2"]]],
"isMaster":"true",
"isSlave":"false",
"indexVersion":1596834098600,
"generation":2,
"master":{
"replicateAfter":["commit"],
"replicationEnabled":"true",
"replicableVersion":1596834098600,
"replicableGeneration":2},
"backup":[
"startTime","Fri Aug 07 21:01:38 UTC 2020",
"fileCount",22,
"status","success",
"snapshotCompletedAt","Fri Aug 07 21:01:38 UTC 2020",
"snapshotName",null,
"directoryName","snapshot.20200807210138698"]}}
{noformat}
> 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
