[
https://issues.apache.org/jira/browse/SOLR-4808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13654660#comment-13654660
]
Mark Miller commented on SOLR-4808:
-----------------------------------
Yeah, this is mainly because this seems like a largish issue to deal with to
make good use of it, so it's sort of been a long term plan.
Because you can create collections and add/remove from them without the
collections api or overseer right now, you could persist a replicationFactor
that is simply wrong and not adjusted for.
My long term plan for this has been:
As the collections api gets better, stop supporting creation of collections by
configuration.
Have the Overseer optionally enforce the replicationFactor over time - if too
few nodes are up, it creates new ones, if for some reason too many are up, it
removes some - using some plugable algorithm.
As part of this, we can also make ZooKeeper the truth for cluster state - so
for example, if you delete a collection and then bring back an old node with a
core for that collection, the Solr instance can know that it should simply
remove that core and not bring the collection back to life.
One step at a time, but I think there is a lot to do to take advantage of the
persisted replicationFactor in a way that makes sense - it wouldn't be too cool
if we persisted a repilcation factor of 4 and then the core admin api was used
to make it actually 6 and the spec never matched with the model again.
> Persist and use replication factor at Collection and Shard level
> ----------------------------------------------------------------
>
> Key: SOLR-4808
> URL: https://issues.apache.org/jira/browse/SOLR-4808
> Project: Solr
> Issue Type: New Feature
> Components: SolrCloud
> Reporter: Anshum Gupta
> Labels: solrcloud
>
> The replication factor for a collection as of now is not persisted and used
> while adding replicas.
> We should save the replication factor at collection factor as well as shard
> level.
--
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: [email protected]
For additional commands, e-mail: [email protected]
