[
https://issues.apache.org/jira/browse/SOLR-4808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13690597#comment-13690597
]
Yonik Seeley commented on SOLR-4808:
------------------------------------
After a little chatting on #solr-dev, I think I understand the source of my
confusion...
I took this "What if a node is asked to join a shard which has enough replicas
according to the replicationFactor?" to mean there was an explicit operator
request for a node to join a shard (which should always succeed if possible
IMO).
The issue seems to be more that when a node is brought up, we don't know if the
shards it has locally were explicitly configured by the user, or just the
result of previous automatic shard assignments. It seems like we should assume
ZK has the truth (i.e. assume the latter). We also don't want shards coming
back from the dead (say we deleted a shard, but one of the replicas was down at
the time). So I think I'm agreeing with Mark's "we should not allow
preconfigured cores".
It also seems like it would be a very useful feature to be able to dynamically
tell the cluster "stop trying to fix things temporarily" via API (i.e. it
shouldn't just be a back compat thing).
> 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
> Assignee: Shalin Shekhar Mangar
> 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]
