[SOLR-9438] Shard split can lose data

• Type: Bug
• Status: Closed
• Priority: Critical
• Resolution: Fixed
• Affects Version/s: 4.10.4, 5.5.2, 6.1, 6.2
• Fix Version/s: 6.2.1, 6.3, 7.0
• Component/s: SolrCloud
• Labels: difficulty-medium impact-high
• Assignee: Shalin Shekhar Mangar
• Reporter: Shalin Shekhar Mangar
• Created: 24/Aug/16 21:00
• Updated: 02/Oct/19 17:23
• Resolved: 12/Sep/16 11:53

Description

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. If the former leader node comes back online, 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’.

Issue Links

• is related to: SOLR-9439 Shard split clean up logic for older failed splits is faulty
• is related to: SOLR-9445 Admin requests are retried by CloudSolrClient and LBHttpSolrClient on failure
• is related to: SOLR-9455 Deleting a sub-shard in recovery state can mark parent shard as inactive

Sub-Tasks

• Shard split can fail to write commit data on shutdown: Closed