Ref Guide: standardize section titles to use headline case

This commit is contained in:
Cassandra Targett 2018-08-09 13:39:00 -05:00
parent e46c6b83a4
commit dfb33e97d0
3 changed files with 11 additions and 11 deletions

View File

@ -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.

View File

@ -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

View File

@ -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.