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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
