[
https://issues.apache.org/jira/browse/SOLR-2765?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jamie Johnson updated SOLR-2765:
--------------------------------
Attachment: cluster_state-file.patch
Ok, so here is what I currently have. The patch named cluster_state-file.patch
creates a /clusterstate zk node with the following
{code:xml}
<?xml version="1.0" encoding="UTF-8" ?>
<clusterstate>
<collectionstate name="testcollection">
<shard name="shard0">
<replica name="testhost:7574_solr_">
<str name="roles">searcher</str>
<str name="node_name">testhost:7574_solr</str>
<str name="url">http://testhost:7574/solr/</str>
</replica>
<replica name="testhost:8983_solr_">
<str name="roles">indexer,searcher</str>
<str name="node_name">testhost:8983_solr</str>
<str name="url">http://testhost:8983/solr/</str>
</replica>
</shard>
</collectionstate>
</clusterstate>
{code}
(Again state currently not implemented). This works like the original
implementation in that you must verify the host is alive in live_nodes. I've
added the logic back in (I'm not using it for anything though) to create the
/collections/testcollection/shards/shard0/testhost:7574_solr_
/collections/testcollection/shards/shard0/testhost:8983_solr_
This allows us to theoretically do what Ted suggested earlier, namely actual
state is in /clusterstate, aspirational state is in /collections but this
requires that there be some cluster leader to manage this properly. I had this
removed, but added it back for now. If we don't need it I'll nix it in another
patch.
> Shard/Node states
> -----------------
>
> Key: SOLR-2765
> URL: https://issues.apache.org/jira/browse/SOLR-2765
> Project: Solr
> Issue Type: Sub-task
> Components: SolrCloud, update
> Reporter: Yonik Seeley
> Fix For: 4.0
>
> Attachments: cluster_state-file.patch, combined.patch,
> incremental_update.patch, scheduled_executors.patch, shard-roles.patch
>
>
> Need state for shards that indicate they are recovering, active/enabled, or
> disabled.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
