[
https://issues.apache.org/jira/browse/SOLR-7932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14702911#comment-14702911
]
Mark Miller commented on SOLR-7932:
-----------------------------------
bq. you still have to deal with clock skew though
Why? Don't both times come from the master?
bq. Do you agree that the timestamp check can be removed there?
I don't think it can just be removed in either case without better replacement
logic.
> 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: [email protected]
For additional commands, e-mail: [email protected]
