You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Cao Manh Dat (JIRA)" <ji...@apache.org> on 2017/08/09 08:16:00 UTC

[jira] [Created] (SOLR-11216) Make PeerSync more robust

Cao Manh Dat created SOLR-11216:
-----------------------------------

             Summary: Make PeerSync more robust
                 Key: SOLR-11216
                 URL: https://issues.apache.org/jira/browse/SOLR-11216
             Project: Solr
          Issue Type: Improvement
      Security Level: Public (Default Security Level. Issues are Public)
            Reporter: Cao Manh Dat


First of all, I will change the issue's title with a better name when I have.

When digging into SOLR-10126. I found a case that can make peerSync fail.
* leader and replica receive update from 1 to 4
* replica stop
* replica miss updates 5, 6
* replica start recovery
## replica buffer updates 7, 8
## replica request versions from leader, 
## replica get recent versions which is 1,2,3,4,7,8
## in the same time leader receive update 9, so it will return updates from 1 to 9 (for request versions)
## replica do peersync and request updates 5, 6, 9 from leader
## replica apply updates 5, 6, 9. Its index does not have update 7, 8 and maxVersionSpecified for fingerprint is 9, therefore compare fingerprint will fail

My idea here is why replica request update 9 (step 6) while it knows that updates with lower version ( update 7, 8 ) are on its buffering tlog. Should we request only updates that lower than the lowest update in its buffering tlog ( < 7 )?

Someone my ask that what if replica won't receive update 9. In that case, leader will put the replica into LIR state, so replica will run recovery process again.




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org