Apache
/
lucene
mirror of https://github.com/apache/lucene.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

SOLR-11990: standardize "co-locate" for "colocate" throughout

This commit is contained in:
Cassandra Targett 2018-08-09 13:29:40 -05:00
parent d1c73ff6f6
commit e46c6b83a4
1 changed files with 12 additions and 12 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

24
solr/solr-ref-guide/src/colocating-collections.adoc
View File

@ -18,24 +18,24 @@
// specific language governing permissions and limitations
// under the License.
Solr provides a way to co-locate a collection with another so that cross-collection joins are always possible.
Solr provides a way to colocate a collection with another so that cross-collection joins are always possible.
The co-location guarantee applies to all future Collection operations made either via Collections API or by Autoscaling
The colocation guarantee applies to all future Collection operations made either via Collections API or by Autoscaling
actions.
A collection may only be colocated with exactly one `withCollection`. However, arbitrarily many collections may be
_linked_ to the same `withCollection`.
== Create Collection using `withCollection`
== Create a Colocated Collection
The Create Collection API supports a parameter named `withCollection` which can be used to specify a collection
with which the replicas of the newly created collection should be co-located. See <<collections-api.adoc#create, Create Collection API>>
with which the replicas of the newly created collection should be colocated. See <<collections-api.adoc#create,Create Collection API>>.
`/admin/collections?action=CREATE&name=techproducts&numShards=1&replicationFactor=2&withCollection=tech_categories`
In the above example, all replicas of the `techproducts` collection will be co-located on a node with at least one
In the above example, all replicas of the `techproducts` collection will be colocated on a node with at least one
replica of the `tech_categories` collection.
== Colocating existing collections
== Colocating Existing Collections
When collections already exist beforehand, the <<collections-api.adoc#modifycollection, Modify Collection API>> can be
used to set the `withCollection` parameter so that the two collections can be linked. This will *not* trigger
changes to the cluster automatically because moving a large number of replicas immediately might de-stabilize the system.
@ -45,20 +45,20 @@ to change the cluster manually.
Example:
`/admin/collections?action=MODIFYCOLLECTION&collection=techproducts&withCollection=tech_categories`
== Deleting colocated collections
== Deleting Colocated Collections
Deleting a collection which has been linked to another will fail unless the link itself is deleted first by using the
<<collections-api.adoc#modifycollection, Modify Collection API>> to un-set the `withCollection` attribute.
Example:
`/admin/collections?action=MODIFYCOLLECTION&collection=techproducts&withCollection=`
== Limitations and caveats
== Limitations and Caveats
The collection being used as the `withCollection` must have one shard only and that shard should be named `shard1`. Note
that when using the default router, the shard name is always set to `shard1` but special care must be taken to name the
shard as `shard1` when using the implicit router.
In case new replicas of the `withCollection` have to be added to maintain the co-location guarantees then the new replicas
In case new replicas of the `withCollection` have to be added to maintain the colocation guarantees then the new replicas
will be of type `NRT` only. Automatically creating replicas of `TLOG` or `PULL` types is not supported.
In case, replicas have to be moved from one node to another, perhaps in response to a node lost trigger, then the target
@ -70,7 +70,7 @@ which can prevent such overloading by e.g. setting the maximum number of cores p
Example:
`{'cores' : '<8', 'node' : '#ANY'}`
The co-location guarantee is one-way only i.e. a collection 'X' co-located with 'Y' will always have one or more
The colocation guarantee is one-way only i.e., a collection 'X' colocated with 'Y' will always have one or more
replicas of 'Y' on any node that has a replica of 'X' but the reverse is not true. There may be nodes which have one or
more replicas of 'Y' but no replicas of 'X'. Such replicas of 'Y' will not be considered a violation of co-location
rules and will not be cleaned up automatically.
more replicas of 'Y' but no replicas of 'X'. Such replicas of 'Y' will not be considered a violation of colocation
rules and will not be cleaned up automatically.