You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@lucene.apache.org by ct...@apache.org on 2018/08/10 17:34:45 UTC
[1/2] lucene-solr:branch_7x: SOLR-11990: standardize "co-locate" for
"colocate" throughout
Repository: lucene-solr
Updated Branches:
refs/heads/branch_7x 2fb8e1071 -> 9cfe6ff5c
SOLR-11990: standardize "co-locate" for "colocate" throughout
Project: http://git-wip-us.apache.org/repos/asf/lucene-solr/repo
Commit: http://git-wip-us.apache.org/repos/asf/lucene-solr/commit/d3829efc
Tree: http://git-wip-us.apache.org/repos/asf/lucene-solr/tree/d3829efc
Diff: http://git-wip-us.apache.org/repos/asf/lucene-solr/diff/d3829efc
Branch: refs/heads/branch_7x
Commit: d3829efc412223386a3e8e722c17b008843d4b8c
Parents: 2fb8e10
Author: Cassandra Targett <ct...@apache.org>
Authored: Thu Aug 9 13:29:40 2018 -0500
Committer: Cassandra Targett <ct...@apache.org>
Committed: Fri Aug 10 12:34:10 2018 -0500
----------------------------------------------------------------------
.../src/colocating-collections.adoc | 24 ++++++++++----------
1 file changed, 12 insertions(+), 12 deletions(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/d3829efc/solr/solr-ref-guide/src/colocating-collections.adoc
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/colocating-collections.adoc b/solr/solr-ref-guide/src/colocating-collections.adoc
index cc6b518..a641b4e 100644
--- a/solr/solr-ref-guide/src/colocating-collections.adoc
+++ b/solr/solr-ref-guide/src/colocating-collections.adoc
@@ -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.
\ No newline at end of file
+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.
[2/2] lucene-solr:branch_7x: Ref Guide: standardize section titles to
use headline case
Posted by ct...@apache.org.
Ref Guide: standardize section titles to use headline case
Project: http://git-wip-us.apache.org/repos/asf/lucene-solr/repo
Commit: http://git-wip-us.apache.org/repos/asf/lucene-solr/commit/9cfe6ff5
Tree: http://git-wip-us.apache.org/repos/asf/lucene-solr/tree/9cfe6ff5
Diff: http://git-wip-us.apache.org/repos/asf/lucene-solr/diff/9cfe6ff5
Branch: refs/heads/branch_7x
Commit: 9cfe6ff5cd2637fccdb8c29ece65fd174c405a6b
Parents: d3829ef
Author: Cassandra Targett <ct...@apache.org>
Authored: Thu Aug 9 13:39:00 2018 -0500
Committer: Cassandra Targett <ct...@apache.org>
Committed: Fri Aug 10 12:34:24 2018 -0500
----------------------------------------------------------------------
solr/solr-ref-guide/src/cloud-screens.adoc | 10 +++++-----
solr/solr-ref-guide/src/coreadmin-api.adoc | 8 ++++----
.../src/solrcloud-query-routing-and-read-tolerance.adoc | 4 ++--
3 files changed, 11 insertions(+), 11 deletions(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/9cfe6ff5/solr/solr-ref-guide/src/cloud-screens.adoc
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/cloud-screens.adoc b/solr/solr-ref-guide/src/cloud-screens.adoc
index cc5a5eb..28160dd 100644
--- a/solr/solr-ref-guide/src/cloud-screens.adoc
+++ b/solr/solr-ref-guide/src/cloud-screens.adoc
@@ -28,26 +28,26 @@ The "Cloud" menu option is only available on Solr instances running in <<getting
Click on the "Cloud" option in the left-hand navigation, and a small sub-menu appears with options called "Nodes", "Tree", "Graph" and "Graph (Radial)". The sub-view selected by default is "Graph".
-== Nodes view
+== Nodes View
The "Nodes" view shows a list of the hosts and nodes in the cluster along with key information for each: "CPU", "Heap", "Disk usage", "Requests", "Collections" and "Replicas".
The example below shows the default "cloud" example with some documents added to the "gettingstarted" collection. Details are expanded for node on port 7574, showing more metadata and more metrics details. The screen provides links to navigate to nodes, collections and replicas. The table supports paging and filtering on host/node names and collection names.
-
+
image::images/cloud-screens/cloud-nodes.png[image,width=900,height=415]
-== Tree view
+== Tree View
The "Tree" view shows a directory structure of the data in ZooKeeper, including cluster wide information regarding the `live_nodes` and `overseer` status, as well as collection specific information such as the `state.json`, current shard leaders, and configuration files in use. In this example, we see part of the `state.json` definition for the "tlog" collection:
image::images/cloud-screens/cloud-tree.png[image,width=487,height=250]
As an aid to debugging, the data shown in the "Tree" view can be exported locally using the following command `bin/solr zk ls -r /`
-== ZK Status view
+== ZK Status View
The "ZK Status" view gives an overview over the Zookeepers used by Solr. It lists whether running in `standalone` or `ensemble` mode, shows how many zookeepers are configured, and then displays a table listing detailed monitoring status for each of the zookeepers, inlcuding who is the leader, configuration parameters and more.
image::images/cloud-screens/cloud-zkstatus.png[image,width=512,height=509]
-== Graph views
+== Graph Views
The "Graph" view shows a graph of each collection, the shards that make up those collections, and the addresses and type ("NRT", "TLOG" or "PULL") of each replica for each shard.
This example shows a simple cluster. In addition to the 2 shard, 2 replica "gettingstarted" collection, there is an additional "tlog" collection consisting of mixed TLOG and PULL replica types.
http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/9cfe6ff5/solr/solr-ref-guide/src/coreadmin-api.adoc
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/coreadmin-api.adoc b/solr/solr-ref-guide/src/coreadmin-api.adoc
index 1b486cd..49895fd 100644
--- a/solr/solr-ref-guide/src/coreadmin-api.adoc
+++ b/solr/solr-ref-guide/src/coreadmin-api.adoc
@@ -269,28 +269,28 @@ Request ID to track this action which will be processed asynchronously.
The `core` index will be split into as many pieces as the number of `path` or `targetCore` parameters.
-==== Usage with two targetCore parameters:
+*Usage with two targetCore parameters*:
[source,bash]
http://localhost:8983/solr/admin/cores?action=SPLIT&core=core0&targetCore=core1&targetCore=core2
Here the `core` index will be split into two pieces and merged into the two `targetCore` indexes.
-==== Usage with two path parameters:
+*Usage with two path parameters*:
[source,bash]
http://localhost:8983/solr/admin/cores?action=SPLIT&core=core0&path=/path/to/index/1&path=/path/to/index/2
The `core` index will be split into two pieces and written into the two directory paths specified.
-==== Usage with the split.key parameter:
+*Usage with the split.key parameter*:
[source,bash]
http://localhost:8983/solr/admin/cores?action=SPLIT&core=core0&targetCore=core1&split.key=A!
Here all documents having the same route key as the `split.key` i.e., 'A!' will be split from the `core` index and written to the `targetCore`.
-==== Usage with ranges parameter:
+*Usage with ranges parameter*:
[source,bash]
http://localhost:8983/solr/admin/cores?action=SPLIT&core=core0&targetCore=core1&targetCore=core2&targetCore=core3&ranges=0-1f4,1f5-3e8,3e9-5dc
http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/9cfe6ff5/solr/solr-ref-guide/src/solrcloud-query-routing-and-read-tolerance.adoc
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/solrcloud-query-routing-and-read-tolerance.adoc b/solr/solr-ref-guide/src/solrcloud-query-routing-and-read-tolerance.adoc
index a3afbad..d6c4fe4 100644
--- a/solr/solr-ref-guide/src/solrcloud-query-routing-and-read-tolerance.adoc
+++ b/solr/solr-ref-guide/src/solrcloud-query-routing-and-read-tolerance.adoc
@@ -115,7 +115,7 @@ http://localhost:8983/solr/collection1/select?q=*:*&_route_=user1!
http://localhost:8983/solr/collection1/select?q=*:*&_route_=user1!,user2!
----
-== Distributed tracing and debugging parameters
+== Distributed Tracing and Debugging Parameters
There are several distributed tracing parameters which can be used to trace the request as well as find timing information for a distributed request.
@@ -125,7 +125,7 @@ There are several distributed tracing parameters which can be used to trace the
|debug=track | Gives debug information for each phase of the distributed query.
|===
-== Optimizations and related parameters
+== Optimizations and Related Parameters
The table below summarizes the general parameters for controlling routing.