[
https://issues.apache.org/jira/browse/SOLR-9438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shalin Shekhar Mangar updated SOLR-9438:
----------------------------------------
Attachment: SOLR-9438.patch
The test failure due to only one node remaining down was because sometimes the
parent leader node itself is selected to host the new sub-shard replica. When
we shutdown that node at the right time, the add replica call fails but the
replica has already been created in the cluster state. Since the physical core
doesn't actually exist, it will never recover and stay in down state.
Changes:
# The test now checks if all replicas actually exist as a core before we wait
for recovery and for sub-shards to switch states.
# The split shard API puts sub-shards into recovery_failed state itself if the
parent leader changes before any replicas can be created.
I've been beasting this test and so far everything looks good but I'll continue
beasting for a little while more.
> Shard split can lose data
> -------------------------
>
> Key: SOLR-9438
> URL: https://issues.apache.org/jira/browse/SOLR-9438
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCloud
> Affects Versions: 4.10.4, 5.5.2, 6.1
> Reporter: Shalin Shekhar Mangar
> Assignee: Shalin Shekhar Mangar
> Priority: Critical
> Labels: difficulty-medium, impact-high
> Fix For: master (7.0), 6.3
>
> Attachments: SOLR-9438-false-replication.log,
> SOLR-9438-split-data-loss.log, SOLR-9438.patch, SOLR-9438.patch,
> SOLR-9438.patch, SOLR-9438.patch, SOLR-9438.patch
>
>
> Solr’s shard split can lose documents if the parent/sub-shard leader is
> killed (or crashes) between the time that the new sub-shard replica is
> created and before it recovers. In such a case the slice has already been set
> to ‘recovery’ state, the sub-shard replica comes up, finds that no other
> replica is up, waits until the leader vote wait time and then proceeds to
> become the leader as well as publish itself as active. Once that happens the
> overseer seeing that all replicas of the sub-shard are now ‘active’, sets the
> parent slice as ‘inactive’ and the new sub-shard as ‘active’.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
