[
https://issues.apache.org/jira/browse/SOLR-10751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomás Fernández Löbbe updated SOLR-10751:
-----------------------------------------
Description:
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.
was:
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.
> 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
> Attachments: SOLR-10751.patch
>
>
> 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.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
