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/20 16:51:00 UTC
[jira] [Updated] (SOLR-12504) Leader should compute its fingerprint
and retrieve recent updates in an atomic way
[ https://issues.apache.org/jira/browse/SOLR-12504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Cao Manh Dat updated SOLR-12504:
--------------------------------
Description:
SOLR-11216 solved many cases in the PeerSync (in doing recovery). But there are still cases when PeerSync will be failed because of mismatch in fingerprint comparison. The main reason here is fingerprint and recent versions of leader is not computed/retrieved in an atomic way.
For example: when an update made into leader's tlog after fingerprint is computed but before recent versions are retrieved.
Leader's fingerprint : (contains updates from 1-10)
Leader's recent versions : (contains updates from 1-12)
Replica's fingerprint : (contains updates from 1-12)
But it seems that blocking updates in leader for {{getVersions}} operation is not a good idea (it will degrade indexing performance) Still struggling on finding a solution.
was:
SOLR-11216 solved many cases in the PeerSync (in doing recovery). But there are still cases when PeerSync will be failed because of mismatch in fingerprint comparison. The main reason here is fingerprint and recent versions of leader is not computed/retrieved in an atomic way.
For example: when an update made into leader's tlog after fingerprint is computed but before recent versions are retrieved.
Leader's fingerprint : (contains updates from 1-10)
Leader's recent versions : (contains updates from 1-12)
Replica's fingerprint : (contains updates from 1-12)
But it seems that blocking updates in leader for {{getVersions}} operation is not a good idea. Still struggling on finding a solution.
> Leader should compute its fingerprint and retrieve recent updates in an atomic way
> ----------------------------------------------------------------------------------
>
> Key: SOLR-12504
> URL: https://issues.apache.org/jira/browse/SOLR-12504
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Cao Manh Dat
> Assignee: Cao Manh Dat
> Priority: Major
>
> SOLR-11216 solved many cases in the PeerSync (in doing recovery). But there are still cases when PeerSync will be failed because of mismatch in fingerprint comparison. The main reason here is fingerprint and recent versions of leader is not computed/retrieved in an atomic way.
> For example: when an update made into leader's tlog after fingerprint is computed but before recent versions are retrieved.
> Leader's fingerprint : (contains updates from 1-10)
> Leader's recent versions : (contains updates from 1-12)
> Replica's fingerprint : (contains updates from 1-12)
> But it seems that blocking updates in leader for {{getVersions}} operation is not a good idea (it will degrade indexing performance) Still struggling on finding a solution.
--
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