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