[
https://issues.apache.org/jira/browse/SOLR-5324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shalin Shekhar Mangar updated SOLR-5324:
----------------------------------------
Attachment: SOLR-5324.patch
Changes:
# A new shard state: 'recovery' is added
# After all sub-shard replicas have been created, the sub-shard state is set to
'recovery'. If replication factor is 1 then the sub-shards are set to 'active'.
The splitshard API returns at this point.
# The state change events in the overseer are used to track when all replicas
of all sub-shards become 'active'. Once that happens, the parent shard is set
to inactive and the sub-shards are set to 'active'.
# To facilitate the above, a slice property called 'parent' is introduced which
is removed once the slice becomes 'active'.
# If the split is retried then we use the 'deleteshard' api to completely
remove the sub-shards before starting the splitting process.
> Make sub shard replica recovery and shard state switch asynchronous
> -------------------------------------------------------------------
>
> Key: SOLR-5324
> URL: https://issues.apache.org/jira/browse/SOLR-5324
> Project: Solr
> Issue Type: Improvement
> Components: SolrCloud
> Reporter: Shalin Shekhar Mangar
> Assignee: Shalin Shekhar Mangar
> Fix For: 5.0, 4.6
>
> Attachments: SOLR-5324.patch
>
>
> Currently the shard split command waits for all replicas of all sub shards to
> recover and then switches the state of parent to inactive and sub-shards to
> active.
> The problem is that shard split (ab)uses the CoreAdmin WaitForState action to
> ask the sub shard leader to wait until the replica states are active. This
> action is prone to timeout.
> We should make the shard state switching asynchronous. Once all replicas of
> all sub-shards are 'active', the shard states should be switched
> automatically.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
