You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Tomás Fernández Löbbe (JIRA)" <ji...@apache.org> on 2017/05/25 21:12:04 UTC

[jira] [Created] (SOLR-10751) Master/Slave IndexVersion conflict

Tomás Fernández Löbbe created SOLR-10751:
--------------------------------------------

             Summary: Master/Slave IndexVersion conflict
                 Key: SOLR-10751
                 URL: https://issues.apache.org/jira/browse/SOLR-10751
             Project: Solr
          Issue Type: Bug
      Security Level: Public (Default Security Level. Issues are Public)
    Affects Versions: master (7.0)
            Reporter: Tomás Fernández Löbbe
            Assignee: Tomás Fernández Löbbe


I’ve been looking at some failures in the replica types tests. One strange failure I noticed is, master and slave share the same version, but have different generation. The IndexFetcher code does more or less this:
{code}
masterVersion = fetchMasterVersion()
masterGeneration = fetchMasterGeneration()

if (masterVersion == 0 && slaveGeneration != 0 && forceReplication) {
   delete my index
   commit locally
   return
} 
if (masterVersion != slaveVersion) {
  fetchIndexFromMaster(masterGeneration)
} else {
  //do nothing, master and slave are in sync.
}
{code}
The problem I see happens with this sequence of events:

delete index in master (not a DBQ=*:*, I mean a complete removal of the index files and reload of the core)
replication happens in slave (sees a version 0, deletes local index and commit)
add document in master and commit

if the commit in master and in the slave happen at the same millisecond*, they both end up with the same version, but different indices. 
I think that in addition of checking for the same version, we should validate that slave and master have the same generation and If not, consider them not in sync, and proceed to the replication.
True, this is a situation that's difficult to happen in a real prod environment and it's more likely to affect tests, but I think the change makes sense. 




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org