I’d prefer it if the alias was required to be removed, or pointed elsewhere, before the collection could be deleted.
As a best practice, I encourage all SolrCloud users to configure an alias to each collection, and use only the alias in their clients. This allows atomic switching between collections with no client changes necessary. It’s pretty handy in the common case that you’re rebuilding a collection because you’ve changed how things are indexed, but you don’t want to take downtime. Variations include an alias per class of client, or even multiple aliases where the client chooses one at random per request, for moving fractional traffic between collections. In this scenario, the alias would also act as a lock, preventing removal of the “live” collection by testifying that some client is using it. I considered this a first-class safety feature in the cluster management tool I wrote: https://github.com/whitepages/solrcloud_manager On 12/9/16, 1:12 PM, "Anshum Gupta" <ans...@anshumgupta.net> wrote: I think that might have just been an oversight. We shouldn't allow creation of an alias for non-existent collections. On a similar note, I think we should also be clearing out the aliases when we DELETE a collection. -Anshum On Fri, Dec 9, 2016 at 12:57 PM Tomás Fernández Löbbe <tomasflo...@gmail.com> wrote: > We currently support requests to CREATEALIAS to collections that don’t > exist. Requests to this alias later result in 404s. If the target > collection is later created, requests to the alias will begin to work. I’m > wondering if someone is relying on this behavior, or if we should validate > the existence of the target collections when creating the alias (and thus, > fail fast in cases of typos or unexpected cluster state) > > Tomás >
