[
https://issues.apache.org/jira/browse/SOLR-11216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16513887#comment-16513887
]
Cao Manh Dat commented on SOLR-11216:
-------------------------------------
Attached patch for Solution 2. Created a new class PeerSyncWithLeader with some
duplications with its original class (PeerSync) but what we will gain here is
an easier to understand flow (fewer flags) and optimized for doing peerSync on
recovery.
Any objections about this separations? [~shalinmangar] [~markrmil...@gmail.com]
> 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
> Priority: Major
> Attachments: SOLR-11216.patch, SOLR-11216.patch, SOLR-11216.patch
>
>
> 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,
> ## in the same time leader receive update 9, so it will return updates from 1
> to 9 (for request versions) when replica get recent versions ( so it will be
> 1,2,3,4,5,6,7,8,9 )
> ## 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
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
