[
https://issues.apache.org/jira/browse/SOLR-11216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cao Manh Dat updated SOLR-11216:
--------------------------------
Description:
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
Second problem here is we can't trust
was:
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.
> Race condition in peerSync
> --------------------------
>
> 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,
> SOLR-11216.patch, 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
> Second problem here is we can't trust
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
