[
https://issues.apache.org/jira/browse/SOLR-12356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16517827#comment-16517827
]
Andrzej Bialecki commented on SOLR-12356:
------------------------------------------
bq. The default RF should be very high.
Why? we don't care about search performance of this collection that much, we
only care about fault tolerance. Having a replica on every node seems an
overkill - if your cluster is likely to lose N-1 nodes you're in a deep trouble
anyway ;)
bq. I don't think a user should know anything about the autoscaling thing to
use .system collection.
They wouldn't have to - the config API can set up / re-config triggers as
necessary.
bq. If replicas are to be created, they should be created automatically.
Yes - and the existing mechanism of autoAddReplicas is already implemented and
it works.
bq. When I say we should not expose the user to the autoscaling framework, it's
desirable to not even have an entry in the autoscaling.json
I disagree - actively hiding this from the users complicates the code and
prevents them from understanding how it works. We can still provide all
necessary simple setup and config options via the config API so that users are
not exposed to the autoscaling API if they don't want to.
> Always auto-create ".system" collection when in SolrCloud mode
> --------------------------------------------------------------
>
> Key: SOLR-12356
> URL: https://issues.apache.org/jira/browse/SOLR-12356
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Andrzej Bialecki
> Priority: Major
>
> The {{.system}} collection is currently used for blobs, and in SolrCloud mode
> it's also used for autoscaling history and as a metrics history store
> (SOLR-11779). It should be automatically created on Overseer start if it's
> missing.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
