Ramkumar Aiyengar created SOLR-7932:
---------------------------------------
Summary: 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
