[jira] [Reopened] (SOLR-11990) Make it possible to co-locate replicas of multiple collections together in a node

["Shalin Shekhar Mangar (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/SOLR-11990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shalin Shekhar Mangar reopened SOLR-11990:
------------------------------------------

Re-opening due to the TestWithCollection failures on jenkins.

Also, [~steve_rowe] reported privately that when a CREATE command fails because of a policy rule violation, the collection metadata remains in ZooKeeper, even though no replicas are added, so the user has to manually delete the zombie collection. This is also due to the changes made in this issue.

> Make it possible to co-locate replicas of multiple collections together in a node
> ---------------------------------------------------------------------------------
>
>                 Key: SOLR-11990
>                 URL: https://issues.apache.org/jira/browse/SOLR-11990
>             Project: Solr
>          Issue Type: New Feature
>      Security Level: Public(Default Security Level. Issues are Public) 
>          Components: AutoScaling, SolrCloud
>            Reporter: Shalin Shekhar Mangar
>            Assignee: Shalin Shekhar Mangar
>            Priority: Major
>             Fix For: master (8.0), 7.5
>
>         Attachments: SOLR-11990.patch, SOLR-11990.patch, SOLR-11990.patch, SOLR-11990.patch, SOLR-11990.patch, SOLR-11990.patch, SOLR-11990.patch
>
>
> It is necessary to co-locate replicas of different collection together in a node when cross-collection joins are performed.
> while creating a collection specify the parameter {{withCollection=other-collection-name}} . This ensure that Solr always ensure that atleast one replica of {{other-collection}} is present with this collection replicas
> This requires changing create collection, create shard and add replica APIs as well because we want a replica of collection A to be created first before a replica of collection B is created so that join queries etc are always possible.
> Some caveats to this implementation:
> # The {{other-collection}} should only have a single shard named "shard1"
> # Any replica of {{other-collection}} created by this feature will be of NRT type
> Removing the above caveats can be a goal of other issues.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org