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 2018/06/11 04:25:00 UTC
[jira] [Comment Edited] (SOLR-11216) Make PeerSync more robust
[ https://issues.apache.org/jira/browse/SOLR-11216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16507649#comment-16507649 ]
Cao Manh Dat edited comment on SOLR-11216 at 6/11/18 4:24 AM:
--------------------------------------------------------------
The problem here relates to "on-wire" updates which get returned in "getVersions" request but do not present in replica's buffering tlog. Here are couples of solution
* Solution 1: After submitting "getVersions" request, the replica will wait for some time. Therefore "on-wire" updates will land on buffering tlog. This is the simplest solution but less robust than solution 2.
* Solution 2: On finding missed updates, the replica will consider buffered updates as missed one. Hence will request these updates from the leader and apply them to its local index -> It will make the fingerprint comparison success.
* Solution 3: On finding missed updates, the replica will consider any updates with version larger than minVersion(buffered updates) are non-missed updates (the "on-wire" updates will be filled on applyBufferedUpdates() call). We only do fingerprint comparison up-to minVersion(buffered updates).
I kinda like Solution 3 because of its efficient and robust, but it comes with the cost of complexity and the effort for proof it.
[~praste] Yeah, that case will be very tricky to solve, but at least we should solve some common cases.
was (Author: caomanhdat):
The problem here relates to "on-wire" updates which get returned in "getVersions" request but do not present in replica's buffering tlog. Here are couples of solution
* Solution 1: After submitting "getVersions" request, the replica will wait for some time. Therefore "on-wire" updates will land on buffering tlog. This is the simplest solution but less robust than solution 2.
* Solution 2: On finding missed updates, the replica will consider buffered updates as missed one. Hence will request these updates from the leader and apply them to its local index -> It will make the fingerprint comparison success.
* Solution 3: On finding missed updates, the replica will consider any updates with version larger than minVersion(buffered updates) are non-missed updates (the "on-wire" updates will be filled on applyBufferedUpdates() call). We only do fingerprint comparison up-to minVersion(buffered updates).
[~praste] Yeah, that case will be very tricky to solve, but at least we should solve some common cases.
> 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
>
> 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org