[
https://issues.apache.org/jira/browse/SOLR-3755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13552307#comment-13552307
]
Yonik Seeley commented on SOLR-3755:
------------------------------------
OK, after chatting w/ Mark a bit, this seems to be his use-case: A
pre-configured cluster w/ no information yet in ZK.
Currently implemented via:
- configuring the collection & shard of each core in solr.xml
- bring all of those cores up
- start indexing (and in 4.0 style, the correct shard is picked via hashing
and splitting up the range according to the currently known shards)
This 4.0 behavior could be replicated via a "lazyHash" router that simply
splits the hash range over currently know shards at the time of every request.
This is fragile and error prone for many users of course, so it would not be a
default. Additionally, we would need code to explicitly specify the router for
a collection (assuming the collection had not already been created).
Somewhat related: control naming of shards. This could be applicable for both
hashing based collections and custom sharding based collections.
shardNames=myshard1,myshard2,myshard3?
> shard splitting
> ---------------
>
> Key: SOLR-3755
> URL: https://issues.apache.org/jira/browse/SOLR-3755
> Project: Solr
> Issue Type: New Feature
> Components: SolrCloud
> Reporter: Yonik Seeley
> Attachments: SOLR-3755.patch, SOLR-3755.patch
>
>
> We can currently easily add replicas to handle increases in query volume, but
> we should also add a way to add additional shards dynamically by splitting
> existing shards.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
