[
https://issues.apache.org/jira/browse/SOLR-4221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13697930#comment-13697930
]
Yonik Seeley commented on SOLR-4221:
------------------------------------
bq. does it also mean if ever the no:of replicas fall below the 'minReplicas' ,
write ops would fail?
I was considering it only as a create-time parameter (not persisted), and had
originally thought about a parameter on updates that could specify the required
replication level for safety. But we really need to think about all the
use-cases we can up front - it could make sense to have additional persisted
properties around replicationFactor.
One use case is expanding your search capacity dynamically by simply starting
up new nodes that automatically become replicas of existing shards. This is
the current behavior today. We need to think about if/how to handle this use
case when we start persisting replicationFactor and if the overseer will
destroy nodes to bring things back to the replication factor. One way would be
to set the replicationFactor really high (to prevent this distruction), but
this could lead to other negatives such as a future GUI displaying the status
of the collection as degraded since the replicationFactor isn't met. Requiring
the user to bump the replicationFactor up before adding new nodes isn't the
friendliest thing given that this will be a very common use case.
> Custom sharding
> ---------------
>
> Key: SOLR-4221
> URL: https://issues.apache.org/jira/browse/SOLR-4221
> Project: Solr
> Issue Type: New Feature
> Reporter: Yonik Seeley
> Assignee: Noble Paul
> Attachments: SOLR-4221.patch
>
>
> Features to let users control everything about sharding/routing.
--
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
