[
https://issues.apache.org/jira/browse/SOLR-7932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14702927#comment-14702927
]
Ramkumar Aiyengar commented on SOLR-7932:
-----------------------------------------
bq. Why? Don't both times come from the master?
A clock skew could cause two different commits to have the same time (commit 1
happens at time X, NTP sets the clock back by 200ms. 200ms later, commit 2
happens). It's not exactly what's in this title (i.e. relying on timestamps
across machines), and you have to be a lot more unlucky, but you can't rely on
wall time even in the same machine.
bq. I don't think it can just be removed in either case without better
replacement logic.
How does the timestamp help currently in the first case? We are anyway using
generations immediately following, so won't you be better off comparing
generations instead to check if replication can be skipped?
> Solr replication relies on timestamps to sync across machines
> -------------------------------------------------------------
>
> Key: SOLR-7932
> URL: https://issues.apache.org/jira/browse/SOLR-7932
> Project: Solr
> Issue Type: Bug
> Components: replication (java)
> Reporter: Ramkumar Aiyengar
> Attachments: SOLR-7932.patch
>
>
> Spinning off SOLR-7859, noticed there that wall time recorded as commit data
> on a commit to check if replication needs to be done. In IndexFetcher, there
> is this code:
> {code}
> if (!forceReplication &&
> IndexDeletionPolicyWrapper.getCommitTimestamp(commit) == latestVersion) {
> //master and slave are already in sync just return
> LOG.info("Slave in sync with master.");
> successfulInstall = true;
> return true;
> }
> {code}
> It appears as if we are checking wall times across machines to check if we
> are in sync, this could go wrong.
> Once a decision is made to replicate, we do seem to use generations instead,
> except for this place below checks both generations and timestamps to see if
> a full copy is needed..
> {code}
> // if the generation of master is older than that of the slave , it
> means they are not compatible to be copied
> // then a new index directory to be created and all the files need to
> be copied
> boolean isFullCopyNeeded = IndexDeletionPolicyWrapper
> .getCommitTimestamp(commit) >= latestVersion
> || commit.getGeneration() >= latestGeneration || forceReplication;
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
