Cao Manh Dat created SOLR-11216:

             Summary: Make PeerSync more robust
                 Key: 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 

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

To unsubscribe, e-mail:
For additional commands, e-mail:

Reply via email to