[
https://issues.apache.org/jira/browse/SOLR-7955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15632931#comment-15632931
]
Shawn Heisey commented on SOLR-7955:
------------------------------------
Another TL;DR comment:
Something I touched on earlier: What will the default value for
replicationFactor be when the collection is automatically built? One idea, but
I'm far from saying it's the best idea, is to set the default to the number of
servers in the cloud.
If the replica count is hard-coded to 2, or uses the number of servers, the
following scenario would result either in no .system collection at all (failed
create due to insufficient servers) or no redundancy: A user sets up a cloud,
initially with one server, then creates a collection on that cloud to try
things out before adding more servers and setting up their real collection(s).
I like the idea of not making the user do things manually, but if a user
proceeds in the cautious manner I just described, I worry that we'll put that
user in a bad situation at a later date when the server containing their
.system collection dies. We can create good documentation, but unless the user
thinks to LOOK for that documentation, they might get a nasty surprise one day.
Related: The reference guide probably needs a section describing problems that
can arise from a lack of understanding, and how to remedy them. A possible
section title: "Gotchas: Solving problems you may not know you have"
> Auto create .system collection on first request if it does not exist
> --------------------------------------------------------------------
>
> Key: SOLR-7955
> URL: https://issues.apache.org/jira/browse/SOLR-7955
> Project: Solr
> Issue Type: Improvement
> Reporter: Jan Høydahl
> Attachments: SOLR-7955.patch
>
>
> Why should a user need to create the {{.system}} collection manually? It
> would simplify instructions related to BLOB store if user could assume it is
> always there.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
