[
https://issues.apache.org/jira/browse/SOLR-7932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14698478#comment-14698478
]
Shawn Heisey commented on SOLR-7932:
------------------------------------
If we don't have (or fix as you're suggesting) any functionality where time
skew causes problems, then we don't really need to worry about it.
But I think we should. Even if Solr itself doesn't care, a user who is
troubleshooting a SorlCloud problem may try to compare the logs on two
machines, or make those logs available to people on the user list for help.
This is probably another in the long list of things I'd like to do, can't get
anyone else interested in, and may prove too difficult for me to figure out.
> 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
>
> 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
