[ 
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-false-replication.log

The attached SOLR-9438-false-replication.log shows another kind of failure. 

# We create the sub-shard replica and restart the leader node
# The leader comes back online. The replica tries to recover.
# Leader reports its version as 0
# Replica seeing the master version as 0, assumes it is an empty index, reports 
the replication successful
# sub-shard becomes active.

The root cause is that after split we do not commit and so the commit timestamp 
(used for version checks) is not written to the index. If the leader is 
restarted, the IndexWriter.close calls a commit on close. Upon restart, the 
leader will report its version as 0 even though it contains data.

> 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
>              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’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]

Reply via email to