[
https://issues.apache.org/jira/browse/SOLR-8950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15227614#comment-15227614
]
Hrishikesh Gadre commented on SOLR-8950:
----------------------------------------
[~hossman] Thanks a lot for the comments. I think using "aliases" is certainly
a pragmatic option to satisfy the requirement and we can use it as a starting
point. I have couple of questions.
- Does aliases incur extra overhead ? If the overhead is not significant,
should we think about providing this support automatically from usability
perspective? e.g. we can define an extra parameter as part of CREATECOLLECTION
action. If this param is set, Solr will create an internal collection and an
alias automatically. Atomic rename and alias feature will also help in
migrating existing users to this design.
- Also in this case, the internal collection is also available for read/write
operations (?). Should we consider an option to hide such collection
permanently? (i.e. such collection can only be accessed via associated alias
name). If such support is implemented, the above mentioned approach will become
robust (instead of relying on users following the best practices).
Can you please share your thoughts?
> Provide an option to "disable" a specified Solr collection
> ----------------------------------------------------------
>
> Key: SOLR-8950
> URL: https://issues.apache.org/jira/browse/SOLR-8950
> Project: Solr
> Issue Type: New Feature
> Components: SolrCloud
> Affects Versions: 4.10.3, trunk
> Reporter: Hrishikesh Gadre
>
> Currently Solr does not provide facility to "disable" read/write requests for
> a specified collection. This is essential for certain admin operations (e.g.
> restore collection data from an earlier snapshot). Without this support, we
> need to bring down the Solr cluster during the snapshot recovery. In case of
> multi-tenant Solr cluster, it is not always feasible to bring down the Solr
> service since it can affect the availability of other collections too.
--
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
