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 2017/07/14 18:35:08 UTC
[10/11] lucene-solr:branch_7_0: SOLR-11050: remove Confluence-style
anchors and fix all incoming links
SOLR-11050: remove Confluence-style anchors and fix all incoming links
Project: http://git-wip-us.apache.org/repos/asf/lucene-solr/repo
Commit: http://git-wip-us.apache.org/repos/asf/lucene-solr/commit/c6771499
Tree: http://git-wip-us.apache.org/repos/asf/lucene-solr/tree/c6771499
Diff: http://git-wip-us.apache.org/repos/asf/lucene-solr/diff/c6771499
Branch: refs/heads/branch_7_0
Commit: c6771499630bc72da1a6b2688597083be366d7ca
Parents: 333906f
Author: Cassandra Targett <ct...@apache.org>
Authored: Wed Jul 12 19:56:48 2017 -0500
Committer: Cassandra Targett <ct...@apache.org>
Committed: Fri Jul 14 13:28:51 2017 -0500
----------------------------------------------------------------------
...uthentication-and-authorization-plugins.adoc | 18 +--
.../src/basic-authentication-plugin.adoc | 2 +-
solr/solr-ref-guide/src/blockjoin-faceting.adoc | 4 +-
.../src/collapse-and-expand-results.adoc | 2 +-
solr/solr-ref-guide/src/collections-api.adoc | 136 +++++++++---------
.../src/collections-core-admin.adoc | 2 +-
.../src/command-line-utilities.adoc | 2 +-
.../src/common-query-parameters.adoc | 4 +-
solr/solr-ref-guide/src/config-api.adoc | 40 ++----
solr/solr-ref-guide/src/configsets-api.adoc | 79 ++++-------
.../src/configuring-solrconfig-xml.adoc | 8 +-
solr/solr-ref-guide/src/content-streams.adoc | 7 +-
solr/solr-ref-guide/src/coreadmin-api.adoc | 29 ++--
.../src/cross-data-center-replication-cdcr.adoc | 140 +++++--------------
.../src/defining-core-properties.adoc | 6 +-
.../src/distributed-requests.adoc | 2 +-
solr/solr-ref-guide/src/documents-screen.adoc | 16 +--
solr/solr-ref-guide/src/enabling-ssl.adoc | 2 +-
solr/solr-ref-guide/src/errata.adoc | 2 -
solr/solr-ref-guide/src/faceting.adoc | 2 +-
.../field-type-definitions-and-properties.adoc | 6 +-
.../src/field-types-included-with-solr.adoc | 6 +-
.../solr-ref-guide/src/filter-descriptions.adoc | 70 ++--------
solr/solr-ref-guide/src/function-queries.adoc | 14 +-
solr/solr-ref-guide/src/graph-traversal.adoc | 32 +----
.../src/hadoop-authentication-plugin.adoc | 2 +-
.../src/implicit-requesthandlers.adoc | 13 +-
solr/solr-ref-guide/src/index-replication.adoc | 15 +-
.../src/indexconfig-in-solrconfig.adoc | 20 +--
solr/solr-ref-guide/src/language-analysis.adoc | 125 ++++-------------
solr/solr-ref-guide/src/learning-to-rank.adoc | 74 +++-------
.../major-changes-from-solr-5-to-solr-6.adoc | 4 +-
.../src/making-and-restoring-backups.adoc | 8 +-
solr/solr-ref-guide/src/managed-resources.adoc | 7 +-
solr/solr-ref-guide/src/merging-indexes.adoc | 4 +-
.../src/near-real-time-searching.adoc | 7 +-
solr/solr-ref-guide/src/other-parsers.adoc | 99 ++++---------
.../src/other-schema-elements.adoc | 2 -
.../src/overview-of-searching-in-solr.adoc | 2 +-
.../src/pagination-of-results.adoc | 4 +-
.../src/performance-statistics-reference.adoc | 4 +-
solr/solr-ref-guide/src/phonetic-matching.adoc | 20 ++-
solr/solr-ref-guide/src/post-tool.adoc | 7 +-
.../src/query-settings-in-solrconfig.adoc | 16 +--
.../read-and-write-side-fault-tolerance.adoc | 6 -
.../src/requestdispatcher-in-solrconfig.adoc | 14 +-
...lers-and-searchcomponents-in-solrconfig.adoc | 12 +-
solr/solr-ref-guide/src/response-writers.adoc | 69 ++++-----
.../src/rule-based-authorization-plugin.adoc | 6 +-
.../src/rule-based-replica-placement.adoc | 4 +-
.../src/running-solr-on-hdfs.adoc | 20 +--
solr/solr-ref-guide/src/running-solr.adoc | 4 +-
solr/solr-ref-guide/src/schema-api.adoc | 4 +-
...schema-factory-definition-in-solrconfig.adoc | 2 +-
solr/solr-ref-guide/src/segments-info.adoc | 2 +-
.../shards-and-indexing-data-in-solrcloud.adoc | 7 +-
.../src/solr-control-script-reference.adoc | 13 +-
solr/solr-ref-guide/src/solr-glossary.adoc | 4 +-
solr/solr-ref-guide/src/spell-checking.adoc | 2 +-
solr/solr-ref-guide/src/stream-decorators.adoc | 16 +--
.../src/streaming-expressions.adoc | 3 -
.../src/taking-solr-to-production.adoc | 23 +--
.../solr-ref-guide/src/the-terms-component.adoc | 13 +-
solr/solr-ref-guide/src/tokenizers.adoc | 14 --
.../src/transforming-result-documents.adoc | 4 +-
.../src/update-request-processors.adoc | 4 +-
.../src/updatehandlers-in-solrconfig.adoc | 8 +-
.../src/updating-parts-of-documents.adoc | 27 ++--
solr/solr-ref-guide/src/upgrading-solr.adoc | 4 +-
.../src/uploading-data-with-index-handlers.adoc | 37 +----
solr/solr-ref-guide/src/using-javascript.adoc | 2 +-
solr/solr-ref-guide/src/using-python.adoc | 2 +-
.../src/using-solr-from-ruby.adoc | 2 +-
...zookeeper-to-manage-configuration-files.adoc | 2 +-
solr/solr-ref-guide/src/velocity-search-ui.adoc | 4 +-
...king-with-currencies-and-exchange-rates.adoc | 2 +-
solr/solr-ref-guide/src/working-with-dates.adoc | 10 --
...rking-with-external-files-and-processes.adoc | 27 ++--
78 files changed, 417 insertions(+), 1020 deletions(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/c6771499/solr/solr-ref-guide/src/authentication-and-authorization-plugins.adoc
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/authentication-and-authorization-plugins.adoc b/solr/solr-ref-guide/src/authentication-and-authorization-plugins.adoc
index 7f1586f..fce8acb 100644
--- a/solr/solr-ref-guide/src/authentication-and-authorization-plugins.adoc
+++ b/solr/solr-ref-guide/src/authentication-and-authorization-plugins.adoc
@@ -27,7 +27,6 @@ All authentication and authorization plugins can work with Solr whether they are
The following section describes how to enable plugins with `security.json` and place them in the proper locations for your mode of operation.
-[[AuthenticationandAuthorizationPlugins-EnablePluginswithsecurity.json]]
== Enable Plugins with security.json
All of the information required to initialize either type of security plugin is stored in a `security.json` file. This file contains 2 sections, one each for authentication and authorization.
@@ -45,7 +44,7 @@ All of the information required to initialize either type of security plugin is
}
----
-The `/security.json` file needs to be in the proper location before a Solr instance comes up so Solr starts with the security plugin enabled. See the section <<AuthenticationandAuthorizationPlugins-Usingsecurity.jsonwithSolr,Using security.json with Solr>> below for information on how to do this.
+The `/security.json` file needs to be in the proper location before a Solr instance comes up so Solr starts with the security plugin enabled. See the section <<Using security.json with Solr>> below for information on how to do this.
Depending on the plugin(s) in use, other information will be stored in `security.json` such as user information or rules to create roles and permissions. This information is added through the APIs for each plugin provided by Solr, or, in the case of a custom plugin, the approach designed by you.
@@ -66,10 +65,8 @@ Here is a more detailed `security.json` example. In this, the Basic authenticati
}}
----
-[[AuthenticationandAuthorizationPlugins-Usingsecurity.jsonwithSolr]]
== Using security.json with Solr
-[[AuthenticationandAuthorizationPlugins-InSolrCloudmode]]
=== In SolrCloud Mode
While configuring Solr to use an authentication or authorization plugin, you will need to upload a `security.json` file to ZooKeeper. The following command writes the file as it uploads it - you could also upload a file that you have already created locally.
@@ -91,7 +88,6 @@ Depending on the authentication and authorization plugin that you use, you may h
Once `security.json` has been uploaded to ZooKeeper, you should use the appropriate APIs for the plugins you're using to update it. You can edit it manually, but you must take care to remove any version data so it will be properly updated across all ZooKeeper nodes. The version data is found at the end of the `security.json` file, and will appear as the letter "v" followed by a number, such as `{"v":138}`.
-[[AuthenticationandAuthorizationPlugins-InStandaloneMode]]
=== In Standalone Mode
When running Solr in standalone mode, you need to create the `security.json` file and put it in the `$SOLR_HOME` directory for your installation (this is the same place you have located `solr.xml` and is usually `server/solr`).
@@ -100,8 +96,7 @@ If you are using <<legacy-scaling-and-distribution.adoc#legacy-scaling-and-distr
You can use the authentication and authorization APIs, but if you are using the legacy scaling model, you will need to make the same API requests on each node separately. You can also edit `security.json` by hand if you prefer.
-[[AuthenticationandAuthorizationPlugins-Authentication]]
-== Authentication
+== Authentication Plugins
Authentication plugins help in securing the endpoints of Solr by authenticating incoming requests. A custom plugin can be implemented by extending the AuthenticationPlugin class.
@@ -110,7 +105,6 @@ An authentication plugin consists of two parts:
. Server-side component, which intercepts and authenticates incoming requests to Solr using a mechanism defined in the plugin, such as Kerberos, Basic Auth or others.
. Client-side component, i.e., an extension of `HttpClientConfigurer`, which enables a SolrJ client to make requests to a secure Solr instance using the authentication mechanism which the server understands.
-[[AuthenticationandAuthorizationPlugins-EnablingaPlugin]]
=== Enabling a Plugin
* Specify the authentication plugin in `/security.json` as in this example:
@@ -126,7 +120,6 @@ An authentication plugin consists of two parts:
* All of the content in the authentication block of `security.json` would be passed on as a map to the plugin during initialization.
* An authentication plugin can also be used with a standalone Solr instance by passing in `-DauthenticationPlugin=<plugin class name>` during startup.
-[[AuthenticationandAuthorizationPlugins-AvailableAuthenticationPlugins]]
=== Available Authentication Plugins
Solr has the following implementations of authentication plugins:
@@ -135,12 +128,10 @@ Solr has the following implementations of authentication plugins:
* <<basic-authentication-plugin.adoc#basic-authentication-plugin,Basic Authentication Plugin>>
* <<hadoop-authentication-plugin.adoc#hadoop-authentication-plugin,Hadoop Authentication Plugin>>
-[[AuthenticationandAuthorizationPlugins-Authorization]]
== Authorization
An authorization plugin can be written for Solr by extending the {solr-javadocs}/solr-core/org/apache/solr/security/AuthorizationPlugin.html[AuthorizationPlugin] interface.
-[[AuthenticationandAuthorizationPlugins-LoadingaCustomPlugin]]
=== Loading a Custom Plugin
* Make sure that the plugin implementation is in the classpath.
@@ -162,21 +153,16 @@ All of the content in the `authorization` block of `security.json` would be pass
The authorization plugin is only supported in SolrCloud mode. Also, reloading the plugin isn't yet supported and requires a restart of the Solr installation (meaning, the JVM should be restarted, not simply a core reload).
====
-[[AuthenticationandAuthorizationPlugins-AvailableAuthorizationPlugins]]
=== Available Authorization Plugins
Solr has one implementation of an authorization plugin:
* <<rule-based-authorization-plugin.adoc#rule-based-authorization-plugin,Rule-Based Authorization Plugin>>
-[[AuthenticationandAuthorizationPlugins-PKISecuringInter-NodeRequests]]
-
-[[AuthenticationandAuthorizationPlugins-PKI]]
== Securing Inter-Node Requests
There are a lot of requests that originate from the Solr nodes itself. For example, requests from overseer to nodes, recovery threads, etc. Each Authentication plugin declares whether it is capable of securing inter-node requests or not. If not, Solr will fall back to using a special internode authentication mechanism where each Solr node is a super user and is fully trusted by other Solr nodes, described below.
-[[AuthenticationandAuthorizationPlugins-PKIAuthenticationPlugin]]
=== PKIAuthenticationPlugin
The PKIAuthenticationPlugin is used when there is any request going on between two Solr nodes, and the configured Authentication plugin does not wish to handle inter-node security.
http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/c6771499/solr/solr-ref-guide/src/basic-authentication-plugin.adoc
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/basic-authentication-plugin.adoc b/solr/solr-ref-guide/src/basic-authentication-plugin.adoc
index 2a48d7c..2d196cf 100644
--- a/solr/solr-ref-guide/src/basic-authentication-plugin.adoc
+++ b/solr/solr-ref-guide/src/basic-authentication-plugin.adoc
@@ -24,7 +24,7 @@ An authorization plugin is also available to configure Solr with permissions to
== Enable Basic Authentication
-To use Basic authentication, you must first create a `security.json` file. This file and where to put it is described in detail in the section <<authentication-and-authorization-plugins.adoc#AuthenticationandAuthorizationPlugins-EnablePluginswithsecurity.json,Enable Plugins with security.json>>.
+To use Basic authentication, you must first create a `security.json` file. This file and where to put it is described in detail in the section <<authentication-and-authorization-plugins.adoc#enable-plugins-with-security-json,Enable Plugins with security.json>>.
For Basic authentication, the `security.json` file must have an `authentication` part which defines the class being used for authentication. Usernames and passwords (as a sha256(password+salt) hash) could be added when the file is created, or can be added later with the Basic authentication API, described below.
http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/c6771499/solr/solr-ref-guide/src/blockjoin-faceting.adoc
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/blockjoin-faceting.adoc b/solr/solr-ref-guide/src/blockjoin-faceting.adoc
index 1a89a57..7f057f0 100644
--- a/solr/solr-ref-guide/src/blockjoin-faceting.adoc
+++ b/solr/solr-ref-guide/src/blockjoin-faceting.adoc
@@ -42,7 +42,7 @@ This example shows how you could add this search components to `solrconfig.xml`
This component can be added into any search request handler. This component work with distributed search in SolrCloud mode.
-Documents should be added in children-parent blocks as described in <<uploading-data-with-index-handlers.adoc#UploadingDatawithIndexHandlers-NestedChildDocuments,indexing nested child documents>>. Examples:
+Documents should be added in children-parent blocks as described in <<uploading-data-with-index-handlers.adoc#nested-child-documents,indexing nested child documents>>. Examples:
.Sample document
[source,xml]
@@ -95,7 +95,7 @@ Documents should be added in children-parent blocks as described in <<uploading-
</add>
----
-Queries are constructed the same way as for a <<other-parsers.adoc#OtherParsers-BlockJoinQueryParsers,Parent Block Join query>>. For example:
+Queries are constructed the same way as for a <<other-parsers.adoc#block-join-query-parsers,Parent Block Join query>>. For example:
[source,text]
----
http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/c6771499/solr/solr-ref-guide/src/collapse-and-expand-results.adoc
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/collapse-and-expand-results.adoc b/solr/solr-ref-guide/src/collapse-and-expand-results.adoc
index 3d610a9..0c0bbd1 100644
--- a/solr/solr-ref-guide/src/collapse-and-expand-results.adoc
+++ b/solr/solr-ref-guide/src/collapse-and-expand-results.adoc
@@ -24,7 +24,7 @@ The Collapsing query parser groups documents (collapsing the result set) accordi
[IMPORTANT]
====
-In order to use these features with SolrCloud, the documents must be located on the same shard. To ensure document co-location, you can define the `router.name` parameter as `compositeId` when creating the collection. For more information on this option, see the section <<shards-and-indexing-data-in-solrcloud.adoc#ShardsandIndexingDatainSolrCloud-DocumentRouting,Document Routing>>.
+In order to use these features with SolrCloud, the documents must be located on the same shard. To ensure document co-location, you can define the `router.name` parameter as `compositeId` when creating the collection. For more information on this option, see the section <<shards-and-indexing-data-in-solrcloud.adoc#document-routing,Document Routing>>.
====
== Collapsing Query Parser
http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/c6771499/solr/solr-ref-guide/src/collections-api.adoc
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/collections-api.adoc b/solr/solr-ref-guide/src/collections-api.adoc
index 3a43d39..662c5fb 100644
--- a/solr/solr-ref-guide/src/collections-api.adoc
+++ b/solr/solr-ref-guide/src/collections-api.adoc
@@ -24,7 +24,7 @@ The Collections API is used to create, remove, or reload collections.
In the context of SolrCloud you can use it to create collections with a specific number of shards and replicas, move replicas or shards, and create or delete collection aliases.
-[[CollectionsAPI-create]]
+[[create]]
== CREATE: Create a Collection
`/admin/collections?action=CREATE&name=_name_`
@@ -45,7 +45,7 @@ The `compositeId` router hashes the value in the uniqueKey field and looks up th
+
When using the `implicit` router, the `shards` parameter is required. When using the `compositeId` router, the `numShards` parameter is required.
+
-For more information, see also the section <<shards-and-indexing-data-in-solrcloud.adoc#ShardsandIndexingDatainSolrCloud-DocumentRouting,Document Routing>>.
+For more information, see also the section <<shards-and-indexing-data-in-solrcloud.adoc#document-routing,Document Routing>>.
`numShards`::
The number of shards to be created as part of the collection. This is a required parameter when the `router.name` is `compositeId`.
@@ -68,7 +68,7 @@ Allows defining the nodes to spread the new collection across. The format is a c
+
If not provided, the CREATE operation will create shard-replicas spread across all live Solr nodes.
+
-Alternatively, use the special value of `EMPTY` to initially create no shard-replica within the new collection and then later use the <<CollectionsAPI-addreplica,ADDREPLICA>> operation to add shard-replicas when and where required.
+Alternatively, use the special value of `EMPTY` to initially create no shard-replica within the new collection and then later use the <<addreplica,ADDREPLICA>> operation to add shard-replicas when and where required.
`createNodeSet.shuffle`::
Controls wether or not the shard-replicas created for this collection will be assigned to the nodes specified by the `createNodeSet` in a sequential manner, or if the list of nodes should be shuffled prior to creating individual replicas.
@@ -89,10 +89,10 @@ Please note that <<realtime-get.adoc#realtime-get,RealTime Get>> or retrieval by
Set core property _name_ to _value_. See the section <<defining-core-properties.adoc#defining-core-properties,Defining core.properties>> for details on supported properties and values.
`autoAddReplicas`::
-When set to `true`, enables automatic addition of replicas on shared file systems (such as HDFS) only. See the section <<running-solr-on-hdfs.adoc#RunningSolronHDFS-AutomaticallyAddReplicasinSolrCloud,autoAddReplicas Settings>> for more details on settings and overrides. The default is `false`.
+When set to `true`, enables automatic addition of replicas on shared file systems (such as HDFS) only. See the section <<running-solr-on-hdfs.adoc#automatically-add-replicas-in-solrcloud,autoAddReplicas Settings>> for more details on settings and overrides. The default is `false`.
`async`::
-Request ID to track this action which will be <<CollectionsAPI-async,processed asynchronously>>.
+Request ID to track this action which will be <<Asynchronous Calls,processed asynchronously>>.
`rule`::
Replica placement rules. See the section <<rule-based-replica-placement.adoc#rule-based-replica-placement,Rule-based Replica Placement>> for details.
@@ -141,7 +141,7 @@ http://localhost:8983/solr/admin/collections?action=CREATE&name=newCollection&nu
</response>
----
-[[CollectionsAPI-modifycollection]]
+[[modifycollection]]
== MODIFYCOLLECTION: Modify Attributes of a Collection
`/admin/collections?action=MODIFYCOLLECTION&collection=_<collection-name>&<attribute-name>=<attribute-value>&<another-attribute-name>=<another-value>_`
@@ -165,10 +165,9 @@ The attributes that can be modified are:
* rule
* snitch
+
-See the <<CollectionsAPI-create,CREATE action>> section above for details on these attributes.
+See the <<create,CREATE action>> section above for details on these attributes.
-
-[[CollectionsAPI-reload]]
+[[reload]]
== RELOAD: Reload a Collection
`/admin/collections?action=RELOAD&name=_name_`
@@ -177,11 +176,11 @@ The RELOAD action is used when you have changed a configuration in ZooKeeper.
=== RELOAD Parameters
-|`name`::
+`name`::
The name of the collection to reload. This parameter is required.
`async`::
-Request ID to track this action which will be <<CollectionsAPI-async,processed asynchronously>>.
+Request ID to track this action which will be <<Asynchronous Calls,processed asynchronously>>.
=== RELOAD Response
@@ -222,7 +221,7 @@ http://localhost:8983/solr/admin/collections?action=RELOAD&name=newCollection
</response>
----
-[[CollectionsAPI-splitshard]]
+[[splitshard]]
== SPLITSHARD: Split a Shard
`/admin/collections?action=SPLITSHARD&collection=_name_&shard=_shardID_`
@@ -233,7 +232,7 @@ This command allows for seamless splitting and requires no downtime. A shard bei
The split is performed by dividing the original shard's hash range into two equal partitions and dividing up the documents in the original shard according to the new sub-ranges. Two parameters discussed below, `ranges` and `split.key` provide further control over how the split occurs.
-Shard splitting can be a long running process. In order to avoid timeouts, you should run this as an <<CollectionsAPI-async,asynchronous call>>.
+Shard splitting can be a long running process. In order to avoid timeouts, you should run this as an <<Asynchronous Calls,asynchronous call>>.
=== SPLITSHARD Parameters
@@ -259,7 +258,7 @@ For example, suppose `split.key=A!` hashes to the range `12-15` and belongs to s
Set core property _name_ to _value_. See the section <<defining-core-properties.adoc#defining-core-properties,Defining core.properties>> for details on supported properties and values.
`async`::
-Request ID to track this action which will be <<CollectionsAPI-async,processed asynchronously>>
+Request ID to track this action which will be <<Asynchronous Calls,processed asynchronously>>
=== SPLITSHARD Response
@@ -338,7 +337,7 @@ http://localhost:8983/solr/admin/collections?action=SPLITSHARD&collection=anothe
</response>
----
-[[CollectionsAPI-createshard]]
+[[createshard]]
== CREATESHARD: Create a Shard
Shards can only created with this API for collections that use the 'implicit' router (i.e., when the collection was created, `router.name=implicit`). A new shard with a name can be created for an existing 'implicit' collection.
@@ -364,7 +363,7 @@ The format is a comma-separated list of node_names, such as `localhost:8983_solr
Set core property _name_ to _value_. See the section <<defining-core-properties.adoc#defining-core-properties,Defining core.properties>> for details on supported properties and values.
`async`::
-Request ID to track this action which will be <<CollectionsAPI-async,processed asynchronously>>.
+Request ID to track this action which will be <<Asynchronous Calls,processed asynchronously>>.
=== CREATESHARD Response
@@ -393,7 +392,7 @@ http://localhost:8983/solr/admin/collections?action=CREATESHARD&collection=anImp
</response>
----
-[[CollectionsAPI-deleteshard]]
+[[deleteshard]]
== DELETESHARD: Delete a Shard
Deleting a shard will unload all replicas of the shard, remove them from `clusterstate.json`, and (by default) delete the instanceDir and dataDir for each replica. It will only remove shards that are inactive, or which have no range given for custom sharding.
@@ -418,7 +417,7 @@ By default Solr will delete the dataDir of each replica that is deleted. Set thi
By default Solr will delete the index of each replica that is deleted. Set this to `false` to prevent the index directory from being deleted.
`async`::
-Request ID to track this action which will be <<CollectionsAPI-async,processed asynchronously>>.
+Request ID to track this action which will be <<Asynchronous Calls,processed asynchronously>>.
=== DELETESHARD Response
@@ -455,7 +454,7 @@ http://localhost:8983/solr/admin/collections?action=DELETESHARD&collection=anoth
</response>
----
-[[CollectionsAPI-createalias]]
+[[createalias]]
== CREATEALIAS: Create or Modify an Alias for a Collection
The `CREATEALIAS` action will create a new alias pointing to one or more collections. If an alias by the same name already exists, this action will replace the existing alias, effectively acting like an atomic "MOVE" command.
@@ -471,14 +470,12 @@ The alias name to be created. This parameter is required.
A comma-separated list of collections to be aliased. The collections must already exist in the cluster. This parameter is required.
`async`::
-Request ID to track this action which will be <<CollectionsAPI-async,processed asynchronously>>.
+Request ID to track this action which will be <<Asynchronous Calls,processed asynchronously>>.
-[[CollectionsAPI-Output.5]]
=== CREATEALIAS Response
The output will simply be a responseHeader with details of the time it took to process the request. To confirm the creation of the alias, you can look in the Solr Admin UI, under the Cloud section and find the `aliases.json` file.
-[[CollectionsAPI-Examples.5]]
=== Examples using CREATEALIAS
*Input*
@@ -502,7 +499,7 @@ http://localhost:8983/solr/admin/collections?action=CREATEALIAS&name=testalias&c
</response>
----
-[[CollectionsAPI-listaliases]]
+[[listaliases]]
== LISTALIASES: List of all aliases in the cluster
`/admin/collections?action=LISTALIASES`
@@ -531,7 +528,7 @@ The output will contain a list of aliases with the corresponding collection name
</response>
----
-[[CollectionsAPI-deletealias]]
+[[deletealias]]
== DELETEALIAS: Delete a Collection Alias
`/admin/collections?action=DELETEALIAS&name=_name_`
@@ -542,7 +539,7 @@ The output will contain a list of aliases with the corresponding collection name
The name of the alias to delete. This parameter is required.
`async`::
-Request ID to track this action which will be <<CollectionsAPI-async,processed asynchronously>>.
+Request ID to track this action which will be <<Asynchronous Calls,processed asynchronously>>.
=== DELETEALIAS Response
@@ -571,7 +568,7 @@ http://localhost:8983/solr/admin/collections?action=DELETEALIAS&name=testalias
</response>
----
-[[CollectionsAPI-delete]]
+[[delete]]
== DELETE: Delete a Collection
`/admin/collections?action=DELETE&name=_collection_`
@@ -582,7 +579,7 @@ http://localhost:8983/solr/admin/collections?action=DELETEALIAS&name=testalias
The name of the collection to delete. This parameter is required.
`async`::
-Request ID to track this action which will be <<CollectionsAPI-async,processed asynchronously>>.
+Request ID to track this action which will be <<Asynchronous Calls,processed asynchronously>>.
=== DELETE Response
@@ -625,7 +622,7 @@ http://localhost:8983/solr/admin/collections?action=DELETE&name=newCollection
</response>
----
-[[CollectionsAPI-deletereplica]]
+[[deletereplica]]
== DELETEREPLICA: Delete a Replica
Deletes a named replica from the specified collection and shard.
@@ -665,7 +662,7 @@ By default Solr will delete the index of the replica that is deleted. Set this t
When set to `true`, no action will be taken if the replica is active. Default `false`.
`async`::
-Request ID to track this action which will be <<CollectionsAPI-async,processed asynchronously>>.
+Request ID to track this action which will be <<Asynchronous Calls,processed asynchronously>>.
=== Examples using DELETEREPLICA
@@ -688,7 +685,7 @@ http://localhost:8983/solr/admin/collections?action=DELETEREPLICA&collection=tes
</response>
----
-[[CollectionsAPI-addreplica]]
+[[addreplica]]
== ADDREPLICA: Add Replica
Add a replica to a shard in a collection. The node name can be specified if the replica is to be created in a specific node.
@@ -722,7 +719,8 @@ The directory in which the core should be created
`property._name_=_value_`::
Set core property _name_ to _value_. See <<defining-core-properties.adoc#defining-core-properties,Defining core.properties>> for details about supported properties and values.
-`async`:: string |No |Request ID to track this action which will be <<CollectionsAPI-async,processed asynchronously>>
+`async`::
+Request ID to track this action which will be <<Asynchronous Calls,processed asynchronously>>
=== Examples using ADDREPLICA
@@ -754,7 +752,7 @@ http://localhost:8983/solr/admin/collections?action=ADDREPLICA&collection=test2&
</response>
----
-[[CollectionsAPI-clusterprop]]
+[[clusterprop]]
== CLUSTERPROP: Cluster Properties
Add, edit or delete a cluster-wide property.
@@ -794,7 +792,7 @@ http://localhost:8983/solr/admin/collections?action=CLUSTERPROP&name=urlScheme&v
</response>
----
-[[CollectionsAPI-migrate]]
+[[migrate]]
== MIGRATE: Migrate Documents to Another Collection
`/admin/collections?action=MIGRATE&collection=_name_&split.key=_key1!_&target.collection=_target_collection_&forward.timeout=60`
@@ -827,7 +825,7 @@ The timeout, in seconds, until which write requests made to the source collectio
Set core property _name_ to _value_. See the section <<defining-core-properties.adoc#defining-core-properties,Defining core.properties>> for details on supported properties and values.
`async`::
-Request ID to track this action which will be <<CollectionsAPI-async,processed asynchronously>>.
+Request ID to track this action which will be <<Asynchronous Calls,processed asynchronously>>.
=== MIGRATE Response
@@ -988,7 +986,7 @@ http://localhost:8983/solr/admin/collections?action=MIGRATE&collection=test1&spl
</response>
----
-[[CollectionsAPI-addrole]]
+[[addrole]]
== ADDROLE: Add a Role
`/admin/collections?action=ADDROLE&role=_roleName_&node=_nodeName_`
@@ -1003,7 +1001,7 @@ Use this command to dedicate a particular node as Overseer. Invoke it multiple t
The name of the role. The only supported role as of now is `overseer`. This parameter is required.
`node`::
-|The name of the node that will be assigned the role. It is possible to assign a role even before that node is started. This parameter is started.
+The name of the node that will be assigned the role. It is possible to assign a role even before that node is started. This parameter is started.
=== ADDROLE Response
@@ -1030,7 +1028,7 @@ http://localhost:8983/solr/admin/collections?action=ADDROLE&role=overseer&node=1
</response>
----
-[[CollectionsAPI-removerole]]
+[[removerole]]
== REMOVEROLE: Remove Role
Remove an assigned role. This API is used to undo the roles assigned using ADDROLE operation
@@ -1046,7 +1044,6 @@ The name of the role. The only supported role as of now is `overseer`. This para
The name of the node where the role should be removed.
-[[CollectionsAPI-Output.11]]
=== REMOVEROLE Response
The response will include the status of the request and the properties that were updated or removed. If the status is anything other than "0", an error message will explain why the request failed.
@@ -1072,7 +1069,7 @@ http://localhost:8983/solr/admin/collections?action=REMOVEROLE&role=overseer&nod
</response>
----
-[[CollectionsAPI-overseerstatus]]
+[[overseerstatus]]
== OVERSEERSTATUS: Overseer Status and Statistics
Returns the current status of the overseer, performance statistics of various overseer APIs, and the last 10 failures per operation type.
@@ -1146,7 +1143,7 @@ http://localhost:8983/solr/admin/collections?action=OVERSEERSTATUS&wt=json
}
----
-[[CollectionsAPI-clusterstatus]]
+[[clusterstatus]]
== CLUSTERSTATUS: Cluster Status
Fetch the cluster status including collections, shards, replicas, configuration name as well as collection aliases and cluster properties.
@@ -1168,7 +1165,6 @@ This can be used if you need the details of the shard where a particular documen
The response will include the status of the request and the status of the cluster.
-[[CollectionsAPI-Examples.15]]
=== Examples using CLUSTERSTATUS
*Input*
@@ -1247,10 +1243,10 @@ http://localhost:8983/solr/admin/collections?action=clusterstatus&wt=json
}
----
-[[CollectionsAPI-requeststatus]]
+[[requeststatus]]
== REQUESTSTATUS: Request Status of an Async Call
-Request the status and response of an already submitted <<CollectionsAPI-async,Asynchronous Collection API>> (below) call. This call is also used to clear up the stored statuses.
+Request the status and response of an already submitted <<Asynchronous Calls,Asynchronous Collection API>> (below) call. This call is also used to clear up the stored statuses.
`/admin/collections?action=REQUESTSTATUS&requestid=_request-id_`
@@ -1307,10 +1303,10 @@ http://localhost:8983/solr/admin/collections?action=REQUESTSTATUS&requestid=1004
</response>
----
-[[CollectionsAPI-deletestatus]]
+[[deletestatus]]
== DELETESTATUS: Delete Status
-Deletes the stored response of an already failed or completed <<CollectionsAPI-async,Asynchronous Collection API>> call.
+Deletes the stored response of an already failed or completed <<Asynchronous Calls,Asynchronous Collection API>> call.
`/admin/collections?action=DELETESTATUS&requestid=_request-id_`
@@ -1384,7 +1380,7 @@ http://localhost:8983/solr/admin/collections?action=DELETESTATUS&flush=true
</response>
----
-[[CollectionsAPI-list]]
+[[list]]
== LIST: List Collections
Fetch the names of the collections in the cluster.
@@ -1413,7 +1409,7 @@ http://localhost:8983/solr/admin/collections?action=LIST&wt=json
"example2"]}
----
-[[CollectionsAPI-addreplicaprop]]
+[[addreplicaprop]]
== ADDREPLICAPROP: Add Replica Property
Assign an arbitrary property to a particular replica and give it the value specified. If the property already exists, it will be overwritten with the new value.
@@ -1501,7 +1497,7 @@ http://localhost:8983/solr/admin/collections?action=ADDREPLICAPROP&shard=shard1&
http://localhost:8983/solr/admin/collections?action=ADDREPLICAPROP&shard=shard1&collection=collection1&replica=core_node3&property=testprop&property.value=value2&shardUnique=true
----
-[[CollectionsAPI-deletereplicaprop]]
+[[deletereplicaprop]]
== DELETEREPLICAPROP: Delete Replica Property
Deletes an arbitrary property from a particular replica.
@@ -1555,7 +1551,7 @@ http://localhost:8983/solr/admin/collections?action=DELETEREPLICAPROP&shard=shar
</response>
----
-[[CollectionsAPI-balanceshardunique]]
+[[balanceshardunique]]
== BALANCESHARDUNIQUE: Balance a Property Across Nodes
`/admin/collections?action=BALANCESHARDUNIQUE&collection=_collectionName_&property=_propertyName_`
@@ -1607,7 +1603,7 @@ http://localhost:8983/solr/admin/collections?action=BALANCESHARDUNIQUE&collectio
Examining the clusterstate after issuing this call should show exactly one replica in each shard that has this property.
-[[CollectionsAPI-rebalanceleaders]]
+[[rebalanceleaders]]
== REBALANCELEADERS: Rebalance Leaders
Reassigns leaders in a collection according to the preferredLeader property across active nodes.
@@ -1709,10 +1705,7 @@ The replica in the "inactivePreferreds" section had the `preferredLeader` proper
Examining the clusterstate after issuing this call should show that every live node that has the `preferredLeader` property should also have the "leader" property set to _true_.
-
-[[CollectionsAPI-FORCELEADER_ForceShardLeader]]
-
-[[CollectionsAPI-forceleader]]
+[[forceleader]]
== FORCELEADER: Force Shard Leader
In the unlikely event of a shard losing its leader, this command can be invoked to force the election of a new leader.
@@ -1729,7 +1722,7 @@ The name of the shard where leader election should occur. This parameter is requ
WARNING: This is an expert level command, and should be invoked only when regular leader election is not working. This may potentially lead to loss of data in the event that the new leader doesn't have certain updates, possibly recent ones, which were acknowledged by the old leader before going down.
-[[CollectionsAPI-migratestateformat]]
+[[migratestateformat]]
== MIGRATESTATEFORMAT: Migrate Cluster State
A expert level utility API to move a collection from shared `clusterstate.json` zookeeper node (created with `stateFormat=1`, the default in all Solr releases prior to 5.0) to the per-collection `state.json` stored in ZooKeeper (created with `stateFormat=2`, the current default) seamlessly without any application down-time.
@@ -1742,11 +1735,11 @@ A expert level utility API to move a collection from shared `clusterstate.json`
The name of the collection to be migrated from `clusterstate.json` to its own `state.json` ZooKeeper node. This parameter is required.
`async`::
-Request ID to track this action which will be <<CollectionsAPI-async,processed asynchronously>>.
+Request ID to track this action which will be <<Asynchronous Calls,processed asynchronously>>.
This API is useful in migrating any collections created prior to Solr 5.0 to the more scalable cluster state format now used by default. If a collection was created in any Solr 5.x version or higher, then executing this command is not necessary.
-[[CollectionsAPI-backup]]
+[[backup]]
== BACKUP: Backup Collection
Backs up Solr collections and associated configurations to a shared filesystem - for example a Network File System.
@@ -1761,15 +1754,15 @@ The BACKUP command will backup Solr indexes and configurations for a specified c
The name of the collection to be backed up. This parameter is required.
`location`::
-The location on a shared drive for the backup command to write to. Alternately it can be set as a <<CollectionsAPI-clusterprop,cluster property>>.
+The location on a shared drive for the backup command to write to. Alternately it can be set as a <<clusterprop,cluster property>>.
`async`::
-Request ID to track this action which will be <<CollectionsAPI-async,processed asynchronously>>.
+Request ID to track this action which will be <<Asynchronous Calls,processed asynchronously>>.
`repository`::
The name of a repository to be used for the backup. If no repository is specified then the local filesystem repository will be used automatically.
-[[CollectionsAPI-restore]]
+[[restore]]
== RESTORE: Restore Collection
Restores Solr indexes and associated configurations.
@@ -1782,7 +1775,7 @@ The collection created will be have the same number of shards and replicas as th
While restoring, if a configSet with the same name exists in ZooKeeper then Solr will reuse that, or else it will upload the backed up configSet in ZooKeeper and use that.
-You can use the collection <<CollectionsAPI-createalias,CREATEALIAS>> command to make sure clients don't need to change the endpoint to query or index against the newly restored collection.
+You can use the collection <<createalias,CREATEALIAS>> command to make sure clients don't need to change the endpoint to query or index against the newly restored collection.
=== RESTORE Parameters
@@ -1790,10 +1783,10 @@ You can use the collection <<CollectionsAPI-createalias,CREATEALIAS>> command to
The collection where the indexes will be restored into. This parameter is required.
`location`::
-The location on a shared drive for the RESTORE command to read from. Alternately it can be set as a <<CollectionsAPI-clusterprop,cluster property>>.
+The location on a shared drive for the RESTORE command to read from. Alternately it can be set as a <<clusterprop,cluster property>>.
`async`::
-Request ID to track this action which will be <<CollectionsAPI-async,processed asynchronously>>.
+Request ID to track this action which will be <<Asynchronous Calls,processed asynchronously>>.
`repository`::
The name of a repository to be used for the backup. If no repository is specified then the local filesystem repository will be used automatically.
@@ -1814,12 +1807,11 @@ When creating collections, the shards and/or replicas are spread across all avai
If a node is not live when the CREATE operation is called, it will not get any parts of the new collection, which could lead to too many replicas being created on a single live node. Defining `maxShardsPerNode` sets a limit on the number of replicas CREATE will spread to each node. If the entire collection can not be fit into the live nodes, no collection will be created at all.
`autoAddReplicas`::
-When set to `true`, enables auto addition of replicas on shared file systems. See the section <<running-solr-on-hdfs.adoc#RunningSolronHDFS-AutomaticallyAddReplicasinSolrCloud,Automatically Add Replicas in SolrCloud>> for more details on settings and overrides.
+When set to `true`, enables auto addition of replicas on shared file systems. See the section <<running-solr-on-hdfs.adoc#automatically-add-replicas-in-solrcloud,Automatically Add Replicas in SolrCloud>> for more details on settings and overrides.
`property._name_=_value_`::
Set core property _name_ to _value_. See the section <<defining-core-properties.adoc#defining-core-properties,Defining core.properties>> for details on supported properties and values.
-[[CollectionsAPI-deletenode]]
== DELETENODE: Delete Replicas in a Node
Deletes all replicas of all collections in that node. Please note that the node itself will remain as a live node after this operation.
@@ -1828,12 +1820,12 @@ Deletes all replicas of all collections in that node. Please note that the node
=== DELETENODE Parameters
-`node`:: string |Yes |The node to be removed. This parameter is required.
+`node`::
+The node to be removed. This parameter is required.
`async`::
-Request ID to track this action which will be <<CollectionsAPI-async,processed asynchronously>>.
+Request ID to track this action which will be <<Asynchronous Calls,processed asynchronously>>.
-[[CollectionsAPI-replacenode]]
== REPLACENODE: Move All Replicas in a Node to Another
This command recreates replicas in one node (the source) to another node (the target). After each replica is copied, the replicas in the source node are deleted.
@@ -1854,7 +1846,7 @@ The target node where replicas will be copied. This parameter is required.
If this flag is set to `true`, all replicas are created in separate threads. Keep in mind that this can lead to very high network and disk I/O if the replicas have very large indices. The default is `false`.
`async`::
-Request ID to track this action which will be <<CollectionsAPI-async,processed asynchronously>>.
+Request ID to track this action which will be <<Asynchronous Calls,processed asynchronously>>.
`timeout`::
Time in seconds to wait until new replicas are created, and until leader replicas are fully recovered. The default is `300`, or 5 minutes.
@@ -1864,7 +1856,6 @@ Time in seconds to wait until new replicas are created, and until leader replica
This operation does not hold necessary locks on the replicas that belong to on the source node. So don't perform other collection operations in this period.
====
-[[CollectionsAPI-movereplica]]
== MOVEREPLICA: Move a Replica to a New Node
This command moves a replica from one node to a new node. In case of shared filesystems the `dataDir` will be reused.
@@ -1889,12 +1880,11 @@ The name of the node that contains the replica. This parameter is required.
The name of the destination node. This parameter is required.
`async`::
-Request ID to track this action which will be <<CollectionsAPI-async,processed asynchronously>>.
+Request ID to track this action which will be <<Asynchronous Calls,processed asynchronously>>.
-[[CollectionsAPI-async]]
== Asynchronous Calls
-Since some collection API calls can be long running tasks (such as SPLITSHARD), you can optionally have the calls run asynchronously. Specifying `async=<request-id>` enables you to make an asynchronous call, the status of which can be requested using the <<CollectionsAPI-requeststatus,REQUESTSTATUS>> call at any time.
+Since some collection API calls can be long running tasks (such as SPLITSHARD), you can optionally have the calls run asynchronously. Specifying `async=<request-id>` enables you to make an asynchronous call, the status of which can be requested using the <<requeststatus,REQUESTSTATUS>> call at any time.
As of now, REQUESTSTATUS does not automatically clean up the tracking data structures, meaning the status of completed or failed tasks stays stored in ZooKeeper unless cleared manually. DELETESTATUS can be used to clear the stored statuses. However, there is a limit of 10,000 on the number of async call responses stored in a cluster.
http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/c6771499/solr/solr-ref-guide/src/collections-core-admin.adoc
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/collections-core-admin.adoc b/solr/solr-ref-guide/src/collections-core-admin.adoc
index fad7560..77d66cf 100644
--- a/solr/solr-ref-guide/src/collections-core-admin.adoc
+++ b/solr/solr-ref-guide/src/collections-core-admin.adoc
@@ -36,6 +36,6 @@ image::images/collections-core-admin/collection-admin.png[image,width=653,height
Replicas can be deleted by clicking the red "X" next to the replica name.
-If the shard is inactive, for example after a <<collections-api.adoc#CollectionsAPI-splitshard,SPLITSHARD action>>, an option to delete the shard will appear as a red "X" next to the shard name.
+If the shard is inactive, for example after a <<collections-api.adoc#splitshard,SPLITSHARD action>>, an option to delete the shard will appear as a red "X" next to the shard name.
image::images/collections-core-admin/DeleteShard.png[image,width=486,height=250]
http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/c6771499/solr/solr-ref-guide/src/command-line-utilities.adoc
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/command-line-utilities.adoc b/solr/solr-ref-guide/src/command-line-utilities.adoc
index 2c0d511..294a1bc 100644
--- a/solr/solr-ref-guide/src/command-line-utilities.adoc
+++ b/solr/solr-ref-guide/src/command-line-utilities.adoc
@@ -150,7 +150,7 @@ This can be useful to create a chroot path in ZooKeeper before first cluster sta
This command will add or modify a single cluster property in `clusterprops.json`. Use this command instead of the usual getfile \-> edit \-> putfile cycle.
-Unlike the CLUSTERPROP command on the <<collections-api.adoc#CollectionsAPI-clusterprop,Collections API>>, this command does *not* require a running Solr cluster.
+Unlike the CLUSTERPROP command on the <<collections-api.adoc#clusterprop,Collections API>>, this command does *not* require a running Solr cluster.
[source,bash]
----
http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/c6771499/solr/solr-ref-guide/src/common-query-parameters.adoc
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/common-query-parameters.adoc b/solr/solr-ref-guide/src/common-query-parameters.adoc
index 826cbe2..1eea080 100644
--- a/solr/solr-ref-guide/src/common-query-parameters.adoc
+++ b/solr/solr-ref-guide/src/common-query-parameters.adoc
@@ -20,7 +20,7 @@
Several query parsers share supported query parameters.
-The table below summarizes Solr's common query parameters, which are supported by the <<requesthandlers-and-searchcomponents-in-solrconfig#RequestHandlersandSearchComponentsinSolrConfig-SearchHandlers,Search RequestHandlers>>
+The table below summarizes Solr's common query parameters, which are supported by the <<requesthandlers-and-searchcomponents-in-solrconfig#searchhandlers,Search RequestHandlers>>
// TODO: Change column width to %autowidth.spread when https://github.com/asciidoctor/asciidoctor-pdf/issues/599 is fixed
@@ -249,7 +249,7 @@ As this check is periodically performed, the actual time for which a request can
This parameter may be set to either true or false.
-If set to true, and if <<indexconfig-in-solrconfig.adoc#IndexConfiginSolrConfig-mergePolicyFactory,the mergePolicyFactory>> for this collection is a {solr-javadocs}/solr-core/org/apache/solr/index/SortingMergePolicyFactory.html[`SortingMergePolicyFactory`] which uses a `sort` option which is compatible with <<CommonQueryParameters-ThesortParameter,the sort parameter>> specified for this query, then Solr will attempt to use an {lucene-javadocs}/core/org/apache/lucene/search/EarlyTerminatingSortingCollector.html[`EarlyTerminatingSortingCollector`].
+If set to true, and if <<indexconfig-in-solrconfig.adoc#mergepolicyfactory,the mergePolicyFactory>> for this collection is a {solr-javadocs}/solr-core/org/apache/solr/index/SortingMergePolicyFactory.html[`SortingMergePolicyFactory`] which uses a `sort` option which is compatible with <<CommonQueryParameters-ThesortParameter,the sort parameter>> specified for this query, then Solr will attempt to use an {lucene-javadocs}/core/org/apache/lucene/search/EarlyTerminatingSortingCollector.html[`EarlyTerminatingSortingCollector`].
If early termination is used, a `segmentTerminatedEarly` header will be included in the `responseHeader`.
http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/c6771499/solr/solr-ref-guide/src/config-api.adoc
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/config-api.adoc b/solr/solr-ref-guide/src/config-api.adoc
index 1b330d0..794b7bf 100644
--- a/solr/solr-ref-guide/src/config-api.adoc
+++ b/solr/solr-ref-guide/src/config-api.adoc
@@ -24,15 +24,13 @@ This feature is enabled by default and works similarly in both SolrCloud and sta
When using this API, `solrconfig.xml` is not changed. Instead, all edited configuration is stored in a file called `configoverlay.json`. The values in `configoverlay.json` override the values in `solrconfig.xml`.
-[[ConfigAPI-APIEntryPoints]]
-== API Entry Points
+== Config API Entry Points
* `/config`: retrieve or modify the config. GET to retrieve and POST for executing commands
* `/config/overlay`: retrieve the details in the `configoverlay.json` alone
* `/config/params` : allows creating parameter sets that can override or take the place of parameters defined in `solrconfig.xml`. See the <<request-parameters-api.adoc#request-parameters-api,Request Parameters API>> section for more details.
-[[ConfigAPI-Retrievingtheconfig]]
-== Retrieving the config
+== Retrieving the Config
All configuration items, can be retrieved by sending a GET request to the `/config` endpoint - the results will be the effective configuration resulting from merging settings in `configoverlay.json` with those in `solrconfig.xml`:
@@ -55,18 +53,16 @@ To further restrict returned results to a single component within a top level se
curl http://localhost:8983/solr/techproducts/config/requestHandler?componentName=/select
----
-[[ConfigAPI-Commandstomodifytheconfig]]
-== Commands to modify the config
+== Commands to Modify the Config
This API uses specific commands to tell Solr what property or type of property to add to `configoverlay.json`. The commands are passed as part of the data sent with the request.
The config commands are categorized into 3 different sections which manipulate various data structures in `solrconfig.xml`. Each of these is described below.
-* <<ConfigAPI-CommandsforCommonProperties,Common Properties>>
-* <<ConfigAPI-CommandsforCustomHandlersandLocalComponents,Components>>
-* <<ConfigAPI-CommandsforUser-DefinedProperties,User-defined properties>>
+* <<Commands for Common Properties,Common Properties>>
+* <<Commands for Custom Handlers and Local Components,Components>>
+* <<Commands for User-Defined Properties,User-defined properties>>
-[[ConfigAPI-CommandsforCommonProperties]]
=== Commands for Common Properties
The common properties are those that are frequently need to be customized in a Solr instance. They are manipulated with two commands:
@@ -119,7 +115,6 @@ The properties that are configured with these commands are predefined and listed
* `requestDispatcher.requestParsers.enableRemoteStreaming`
* `requestDispatcher.requestParsers.addHttpRequestToContext`
-[[ConfigAPI-CommandsforCustomHandlersandLocalComponents]]
=== Commands for Custom Handlers and Local Components
Custom request handlers, search components, and other types of localized Solr components (such as custom query parsers, update processors, etc.) can be added, updated and deleted with specific commands for the component being modified.
@@ -132,7 +127,6 @@ Settings removed from `configoverlay.json` are not removed from `solrconfig.xml`
The full list of available commands follows below:
-[[ConfigAPI-GeneralPurposeCommands]]
==== General Purpose Commands
These commands are the most commonly used:
@@ -150,7 +144,6 @@ These commands are the most commonly used:
* `update-queryresponsewriter`
* `delete-queryresponsewriter`
-[[ConfigAPI-AdvancedCommands]]
==== Advanced Commands
These commands allow registering more advanced customizations to Solr:
@@ -178,9 +171,8 @@ These commands allow registering more advanced customizations to Solr:
* `update-runtimelib`
* `delete-runtimelib`
-See the section <<ConfigAPI-CreatingandUpdatingRequestHandlers,Creating and Updating Request Handlers>> below for examples of using these commands.
+See the section <<Creating and Updating Request Handlers>> below for examples of using these commands.
-[[ConfigAPI-Whatabout_updateRequestProcessorChain_]]
==== What about updateRequestProcessorChain?
The Config API does not let you create or edit `updateRequestProcessorChain` elements. However, it is possible to create `updateProcessor` entries and can use them by name to create a chain.
@@ -197,7 +189,6 @@ curl http://localhost:8983/solr/techproducts/config -H 'Content-type:application
You can use this directly in your request by adding a parameter in the `updateRequestProcessorChain` for the specific update processor called `processor=firstFld`.
-[[ConfigAPI-CommandsforUser-DefinedProperties]]
=== Commands for User-Defined Properties
Solr lets users templatize the `solrconfig.xml` using the place holder format `${variable_name:default_val}`. You could set the values using system properties, for example, `-Dvariable_name= my_customvalue`. The same can be achieved during runtime using these commands:
@@ -207,11 +198,10 @@ Solr lets users templatize the `solrconfig.xml` using the place holder format `$
The structure of the request is similar to the structure of requests using other commands, in the format of `"command":{"variable_name":"property_value"}`. You can add more than one variable at a time if necessary.
-For more information about user-defined properties, see the section <<configuring-solrconfig-xml.adoc#Configuringsolrconfig.xml-Userdefinedpropertiesfromcore.properties,User defined properties from core.properties>>.
+For more information about user-defined properties, see the section <<configuring-solrconfig-xml.adoc#user-defined-properties-in-core-properties,User defined properties in core.properties>>.
-See also the section <<ConfigAPI-CreatingandUpdatingUser-DefinedProperties,Creating and Updating User-Defined Properties>> below for examples of how to use this type of command.
+See also the section <<Creating and Updating User-Defined Properties>> below for examples of how to use this type of command.
-[[ConfigAPI-HowtoMapsolrconfig.xmlPropertiestoJSON]]
== How to Map solrconfig.xml Properties to JSON
By using this API, you will be generating JSON representations of properties defined in `solrconfig.xml`. To understand how properties should be represented with the API, let's take a look at a few examples.
@@ -363,15 +353,12 @@ Define the same properties with the Config API:
}
----
-[[ConfigAPI-NameComponentsfortheConfigAPI]]
=== Name Components for the Config API
The Config API always allows changing the configuration of any component by name. However, some configurations such as `listener` or `initParams` do not require a name in `solrconfig.xml`. In order to be able to `update` and `delete` of the same item in `configoverlay.json`, the name attribute becomes mandatory.
-[[ConfigAPI-Examples]]
-== Examples
+== Config API Examples
-[[ConfigAPI-CreatingandUpdatingCommonProperties]]
=== Creating and Updating Common Properties
This change sets the `query.filterCache.autowarmCount` to 1000 items and unsets the `query.filterCache.size`.
@@ -402,7 +389,6 @@ And you should get a response like this:
"size":25}}}}}
----
-[[ConfigAPI-CreatingandUpdatingRequestHandlers]]
=== Creating and Updating Request Handlers
To create a request handler, we can use the `add-requesthandler` command:
@@ -470,7 +456,6 @@ curl http://localhost:8983/solr/techproducts/config -H 'Content-type:application
}'
----
-[[ConfigAPI-CreatingandUpdatingUser-DefinedProperties]]
=== Creating and Updating User-Defined Properties
This command sets a user property.
@@ -506,14 +491,12 @@ To unset the variable, issue a command like this:
curl http://localhost:8983/solr/techproducts/config -H'Content-type:application/json' -d '{"unset-user-property" : "variable_name"}'
----
-[[ConfigAPI-HowItWorks]]
-== How It Works
+== How the Config API Works
Every core watches the ZooKeeper directory for the configset being used with that core. In standalone mode, however, there is no watch (because ZooKeeper is not running). If there are multiple cores in the same node using the same configset, only one ZooKeeper watch is used. For instance, if the configset 'myconf' is used by a core, the node would watch `/configs/myconf`. Every write operation performed through the API would 'touch' the directory (sets an empty byte[] to trigger watches) and all watchers are notified. Every core would check if the Schema file, `solrconfig.xml` or `configoverlay.json` is modified by comparing the `znode` versions and if modified, the core is reloaded.
If `params.json` is modified, the params object is just updated without a core reload (see the section <<request-parameters-api.adoc#request-parameters-api,Request Parameters API>> for more information about `params.json`).
-[[ConfigAPI-EmptyCommand]]
=== Empty Command
If an empty command is sent to the `/config` endpoint, the watch is triggered on all cores using this configset. For example:
@@ -527,7 +510,6 @@ Directly editing any files without 'touching' the directory *will not* make it v
It is possible for components to watch for the configset 'touch' events by registering a listener using `SolrCore#registerConfListener()` .
-[[ConfigAPI-ListeningtoconfigChanges]]
=== Listening to config Changes
Any component can register a listener using:
http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/c6771499/solr/solr-ref-guide/src/configsets-api.adoc
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/configsets-api.adoc b/solr/solr-ref-guide/src/configsets-api.adoc
index 603e08e..cae9b13 100644
--- a/solr/solr-ref-guide/src/configsets-api.adoc
+++ b/solr/solr-ref-guide/src/configsets-api.adoc
@@ -1,6 +1,7 @@
= ConfigSets API
:page-shortname: configsets-api
:page-permalink: configsets-api.html
+:page-toclevels: 1
// Licensed to the Apache Software Foundation (ASF) under one
// or more contributor license agreements. See the NOTICE file
// distributed with this work for additional information
@@ -24,45 +25,40 @@ To use a ConfigSet created with this API as the configuration for a collection,
This API can only be used with Solr running in SolrCloud mode. If you are not running Solr in SolrCloud mode but would still like to use shared configurations, please see the section <<config-sets.adoc#config-sets,Config Sets>>.
-[[ConfigSetsAPI-APIEntryPoints]]
-== API Entry Points
+== ConfigSets API Entry Points
The base URL for all API calls is `\http://<hostname>:<port>/solr`.
-* `/admin/configs?action=CREATE`: <<ConfigSetsAPI-create,create>> a ConfigSet, based on an existing ConfigSet
-* `/admin/configs?action=DELETE`: <<ConfigSetsAPI-delete,delete>> a ConfigSet
-* `/admin/configs?action=LIST`: <<ConfigSetsAPI-list,list>> all ConfigSets
-* `/admin/configs?action=UPLOAD`: <<ConfigSetsAPI-upload,upload>> a ConfigSet
+* `/admin/configs?action=CREATE`: <<configsets-create,create>> a ConfigSet, based on an existing ConfigSet
+* `/admin/configs?action=DELETE`: <<configsets-delete,delete>> a ConfigSet
+* `/admin/configs?action=LIST`: <<configsets-list,list>> all ConfigSets
+* `/admin/configs?action=UPLOAD`: <<configsets-upload,upload>> a ConfigSet
-[[ConfigSetsAPI-createCreateaConfigSet]]
-
-[[ConfigSetsAPI-create]]
+[[configsets-create]]
== Create a ConfigSet
`/admin/configs?action=CREATE&name=_name_&baseConfigSet=_baseConfigSet_`
Create a ConfigSet, based on an existing ConfigSet.
-[[ConfigSetsAPI-Input]]
-=== Input
+=== Create ConfigSet Parameters
The following parameters are supported when creating a ConfigSet.
-name:: The ConfigSet to be created. This parameter is required.
-
-baseConfigSet:: The ConfigSet to copy as a base. This parameter is required.
+name::
+The ConfigSet to be created. This parameter is required.
-configSetProp._name_=_value_:: Any ConfigSet property from base to override.
+baseConfigSet::
+The ConfigSet to copy as a base. This parameter is required.
-[[ConfigSetsAPI-Output]]
-=== Output
+configSetProp._name_=_value_::
+Any ConfigSet property from base to override.
-*Output Content*
+=== Create ConfigSet Response
-The output will include the status of the request. If the status is anything other than "success", an error message will explain why the request failed.
+The response will include the status of the request. If the status is anything other than "success", an error message will explain why the request failed.
-[[ConfigSetsAPI-Examples]]
-=== Examples
+=== Create ConfigSet Examples
*Input*
@@ -85,31 +81,23 @@ http://localhost:8983/solr/admin/configs?action=CREATE&name=myConfigSet&baseConf
</response>
----
-[[ConfigSetsAPI-deleteDeleteaConfigSet]]
-
-[[ConfigSetsAPI-delete]]
+[[configsets-delete]]
== Delete a ConfigSet
`/admin/configs?action=DELETE&name=_name_`
Delete a ConfigSet
-[[ConfigSetsAPI-Input.1]]
-=== Input
+=== Delete ConfigSet Parameters
-*Query Parameters*
+name::
+The ConfigSet to be deleted. This parameter is required.
-name:: The ConfigSet to be deleted. This parameter is required.
-
-[[ConfigSetsAPI-Output.1]]
-=== Output
-
-*Output Content*
+=== Delete ConfigSet Response
The output will include the status of the request. If the status is anything other than "success", an error message will explain why the request failed.
-[[ConfigSetsAPI-Examples.1]]
-=== Examples
+=== Delete ConfigSet Examples
*Input*
@@ -132,15 +120,14 @@ http://localhost:8983/solr/admin/configs?action=DELETE&name=myConfigSet
</response>
----
-[[ConfigSetsAPI-list]]
+[[configsets-list]]
== List ConfigSets
`/admin/configs?action=LIST`
Fetch the names of the ConfigSets in the cluster.
-[[ConfigSetsAPI-Examples.2]]
-=== Examples
+=== List ConfigSet Examples
*Input*
@@ -161,7 +148,7 @@ http://localhost:8983/solr/admin/configs?action=LIST&wt=json
"myConfig2"]}
----
-[[ConfigSetsAPI-upload]]
+[[configsets-upload]]
== Upload a ConfigSet
`/admin/configs?action=UPLOAD&name=_name_`
@@ -173,22 +160,18 @@ Upload a ConfigSet, sent in as a zipped file. Please note that a ConfigSet is up
* XSLT transformer (tr parameter) cannot be used at request processing time.
* StatelessScriptUpdateProcessor does not initialize, if specified in the ConfigSet.
-[[ConfigSetsAPI-Input.3]]
-=== Input
+=== Upload ConfigSet Parameters
-name:: The ConfigSet to be created when the upload is complete. This parameter is required.
+name::
+The ConfigSet to be created when the upload is complete. This parameter is required.
The body of the request should contain a zipped config set.
-[[ConfigSetsAPI-Output.3]]
-=== Output
-
-*Output Content*
+=== Upload ConfigSet Response
The output will include the status of the request. If the status is anything other than "success", an error message will explain why the request failed.
-[[ConfigSetsAPI-Examples.3]]
-=== Examples
+=== Upload ConfigSet Examples
Create a ConfigSet named 'myConfigSet' based on a 'predefinedTemplate' ConfigSet, overriding the immutable property to false.
http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/c6771499/solr/solr-ref-guide/src/configuring-solrconfig-xml.adoc
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/configuring-solrconfig-xml.adoc b/solr/solr-ref-guide/src/configuring-solrconfig-xml.adoc
index 48f9084..7888e29 100644
--- a/solr/solr-ref-guide/src/configuring-solrconfig-xml.adoc
+++ b/solr/solr-ref-guide/src/configuring-solrconfig-xml.adoc
@@ -51,14 +51,12 @@ We've covered the options in the following sections:
* <<update-request-processors.adoc#update-request-processors,Update Request Processors>>
* <<codec-factory.adoc#codec-factory,Codec Factory>>
-[[Configuringsolrconfig.xml-SubstitutingPropertiesinSolrConfigFiles]]
== Substituting Properties in Solr Config Files
Solr supports variable substitution of property values in config files, which allows runtime specification of various configuration options in `solrconfig.xml`. The syntax is `${propertyname[:option default value]`}. This allows defining a default that can be overridden when Solr is launched. If a default value is not specified, then the property _must_ be specified at runtime or the configuration file will generate an error when parsed.
There are multiple methods for specifying properties that can be used in configuration files. Of those below, strongly consider "config overlay" as the preferred approach, as it stays local to the config set and because it's easy to modify.
-[[Configuringsolrconfig.xml-JVMSystemProperties]]
=== JVM System Properties
Any JVM System properties, usually specified using the `-D` flag when starting the JVM, can be used as variables in any XML configuration file in Solr.
@@ -79,8 +77,7 @@ bin/solr start -Dsolr.lock.type=none
In general, any Java system property that you want to set can be passed through the `bin/solr` script using the standard `-Dproperty=value` syntax. Alternatively, you can add common system properties to the `SOLR_OPTS` environment variable defined in the Solr include file (`bin/solr.in.sh` or `bin/solr.in.cmd`). For more information about how the Solr include file works, refer to: <<taking-solr-to-production.adoc#taking-solr-to-production,Taking Solr to Production>>.
-[[Configuringsolrconfig.xml-ConfigAPI]]
-=== Config API
+=== Config API to Override solrconfig.xml
The <<config-api.adoc#config-api,Config API>> allows you to use an API to modify Solr's configuration, specifically user defined properties. Changes made with this API are stored in a file named `configoverlay.json`. This file should only be edited with the API, but will look like this example:
@@ -94,7 +91,6 @@ The <<config-api.adoc#config-api,Config API>> allows you to use an API to modify
For more details, see the section <<config-api.adoc#config-api,Config API>>.
-[[Configuringsolrconfig.xml-solrcore.properties]]
=== solrcore.properties
If the configuration directory for a Solr core contains a file named `solrcore.properties` that file can contain any arbitrary user defined property names and values using the Java standard https://en.wikipedia.org/wiki/.properties[properties file format], and those properties can be used as variables in the XML configuration files for that Solr core.
@@ -120,7 +116,6 @@ The path and name of the `solrcore.properties` file can be overridden using the
====
-[[Configuringsolrconfig.xml-Userdefinedpropertiesfromcore.properties]]
=== User-Defined Properties in core.properties
Every Solr core has a `core.properties` file, automatically created when using the APIs. When you create a SolrCloud collection, you can pass through custom parameters to go into each core.properties that will be created, by prefixing the parameter name with "property." as a URL parameter. Example:
@@ -148,7 +143,6 @@ The `my.custom.prop` property can then be used as a variable, such as in `solrco
</requestHandler>
----
-[[Configuringsolrconfig.xml-ImplicitCoreProperties]]
=== Implicit Core Properties
Several attributes of a Solr core are available as "implicit" properties that can be used in variable substitution, independent of where or how they underlying value is initialized. For example: regardless of whether the name for a particular Solr core is explicitly configured in `core.properties` or inferred from the name of the instance directory, the implicit property `solr.core.name` is available for use as a variable in that core's configuration file...
http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/c6771499/solr/solr-ref-guide/src/content-streams.adoc
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/content-streams.adoc b/solr/solr-ref-guide/src/content-streams.adoc
index f5f01a8..c4fc194 100644
--- a/solr/solr-ref-guide/src/content-streams.adoc
+++ b/solr/solr-ref-guide/src/content-streams.adoc
@@ -22,8 +22,7 @@ Content streams are bulk data passed with a request to Solr.
When Solr RequestHandlers are accessed using path based URLs, the `SolrQueryRequest` object containing the parameters of the request may also contain a list of ContentStreams containing bulk data for the request. (The name SolrQueryRequest is a bit misleading: it is involved in all requests, regardless of whether it is a query request or an update request.)
-[[ContentStreams-StreamSources]]
-== Stream Sources
+== Content Stream Sources
Currently request handlers can get content streams in a variety of ways:
@@ -34,7 +33,6 @@ Currently request handlers can get content streams in a variety of ways:
By default, curl sends a `contentType="application/x-www-form-urlencoded"` header. If you need to test a SolrContentHeader content stream, you will need to set the content type with curl's `-H` flag.
-[[ContentStreams-RemoteStreaming]]
== RemoteStreaming
Remote streaming lets you send the contents of a URL as a stream to a given SolrRequestHandler. You could use remote streaming to send a remote or local file to an update plugin.
@@ -65,10 +63,9 @@ curl -d '
[IMPORTANT]
====
-If `enableRemoteStreaming="true"` is used, be aware that this allows _anyone_ to send a request to any URL or local file. If <<ContentStreams-DebuggingRequests,DumpRequestHandler>> is enabled, it will allow anyone to view any file on your system.
+If `enableRemoteStreaming="true"` is used, be aware that this allows _anyone_ to send a request to any URL or local file. If the <<Debugging Requests,DumpRequestHandler>> is enabled, it will allow anyone to view any file on your system.
====
-[[ContentStreams-DebuggingRequests]]
== Debugging Requests
The implicit "dump" RequestHandler (see <<implicit-requesthandlers.adoc#implicit-requesthandlers,Implicit RequestHandlers>>) simply outputs the contents of the SolrQueryRequest using the specified writer type `wt`. This is a useful tool to help understand what streams are available to the RequestHandlers.
http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/c6771499/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 a4a8ea9..6758701 100644
--- a/solr/solr-ref-guide/src/coreadmin-api.adoc
+++ b/solr/solr-ref-guide/src/coreadmin-api.adoc
@@ -29,7 +29,7 @@ CoreAdmin actions can be executed by via HTTP requests that specify an `action`
All action names are uppercase, and are defined in depth in the sections below.
-[[CoreAdminAPI-STATUS]]
+[[coreadmin-status]]
== STATUS
The `STATUS` action returns the status of all running Solr cores, or status for only the named core.
@@ -44,7 +44,7 @@ The name of a core, as listed in the "name" attribute of a `<core>` element in `
`indexInfo`::
If `false`, information about the index will not be returned with a core STATUS request. In Solr implementations with a large number of cores (i.e., more than hundreds), retrieving the index information for each core can take a lot of time and isn't always required. The default is `true`.
-[[CoreAdminAPI-CREATE]]
+[[coreadmin-create]]
== CREATE
The `CREATE` action creates a new core and registers it.
@@ -102,7 +102,7 @@ WARNING: While it's possible to create a core for a non-existent collection, thi
The shard id this core represents. Normally you want to be auto-assigned a shard id.
`property._name_=_value_`::
-Sets the core property _name_ to _value_. See the section on defining <<defining-core-properties.adoc#Definingcore.properties-core.properties_files,core.properties file contents>>.
+Sets the core property _name_ to _value_. See the section on defining <<defining-core-properties.adoc#defining-core-properties-files,core.properties file contents>>.
`async`::
Request ID to track this action which will be processed asynchronously.
@@ -115,7 +115,7 @@ Use `collection.configName=_configname_` to point to the config for a new collec
http://localhost:8983/solr/admin/cores?action=CREATE&name=my_core&collection=my_collection&shard=shard2
-[[CoreAdminAPI-RELOAD]]
+[[coreadmin-reload]]
== RELOAD
The RELOAD action loads a new core from the configuration of an existing, registered Solr core. While the new core is initializing, the existing one will continue to handle requests. When the new Solr core is ready, it takes over and the old core is unloaded.
@@ -134,7 +134,7 @@ RELOAD performs "live" reloads of SolrCore, reusing some existing objects. Some
`core`::
The name of the core, as listed in the "name" attribute of a `<core>` element in `solr.xml`. This parameter is required.
-[[CoreAdminAPI-RENAME]]
+[[coreadmin-rename]]
== RENAME
The `RENAME` action changes the name of a Solr core.
@@ -153,7 +153,7 @@ The new name for the Solr core. If the persistent attribute of `<solr>` is `true
Request ID to track this action which will be processed asynchronously.
-[[CoreAdminAPI-SWAP]]
+[[coreadmin-swap]]
== SWAP
`SWAP` atomically swaps the names used to access two existing Solr cores. This can be used to swap new content into production. The prior core remains available and can be swapped back, if necessary. Each core will be known by the name of the other, after the swap.
@@ -162,9 +162,7 @@ Request ID to track this action which will be processed asynchronously.
[IMPORTANT]
====
-
Do not use `SWAP` with a SolrCloud node. It is not supported and can result in the core being unusable.
-
====
=== SWAP Parameters
@@ -179,7 +177,7 @@ The name of one of the cores to be swapped. This parameter is required.
Request ID to track this action which will be processed asynchronously.
-[[CoreAdminAPI-UNLOAD]]
+[[coreadmin-unload]]
== UNLOAD
The `UNLOAD` action removes a core from Solr. Active requests will continue to be processed, but no new requests will be sent to the named core. If a core is registered under more than one name, only the given name is removed.
@@ -210,8 +208,7 @@ If `true`, removes everything related to the core, including the index directory
`async`::
Request ID to track this action which will be processed asynchronously.
-
-[[CoreAdminAPI-MERGEINDEXES]]
+[[coreadmin-mergeindexes]]
== MERGEINDEXES
The `MERGEINDEXES` action merges one or more indexes to another index. The indexes must have completed commits, and should be locked against writes until the merge is complete or the resulting merged index may become corrupted. The target core index must already exist and have a compatible schema with the one or more indexes that will be merged to it. Another commit on the target core should also be performed after the merge is complete.
@@ -243,7 +240,7 @@ Multi-valued, source cores that would be merged.
Request ID to track this action which will be processed asynchronously
-[[CoreAdminAPI-SPLIT]]
+[[coreadmin-split]]
== SPLIT
The `SPLIT` action splits an index into two or more indexes. The index being split can continue to handle requests. The split pieces can be placed into a specified directory on the server's filesystem or it can be merged into running Solr cores.
@@ -270,7 +267,6 @@ The key to be used for splitting the index. If this parameter is used, `ranges`
`async`::
Request ID to track this action which will be processed asynchronously.
-
=== SPLIT Examples
The `core` index will be split into as many pieces as the number of `path` or `targetCore` parameters.
@@ -305,9 +301,9 @@ This example uses the `ranges` parameter with hash ranges 0-500, 501-1000 and 10
The `targetCore` must already exist and must have a compatible schema with the `core` index. A commit is automatically called on the `core` index before it is split.
-This command is used as part of the <<collections-api.adoc#CollectionsAPI-splitshard,SPLITSHARD>> command but it can be used for non-cloud Solr cores as well. When used against a non-cloud core without `split.key` parameter, this action will split the source index and distribute its documents alternately so that each split piece contains an equal number of documents. If the `split.key` parameter is specified then only documents having the same route key will be split from the source index.
+This command is used as part of the <<collections-api.adoc#splitshard,SPLITSHARD>> command but it can be used for non-cloud Solr cores as well. When used against a non-cloud core without `split.key` parameter, this action will split the source index and distribute its documents alternately so that each split piece contains an equal number of documents. If the `split.key` parameter is specified then only documents having the same route key will be split from the source index.
-[[CoreAdminAPI-REQUESTSTATUS]]
+[[coreadmin-requeststatus]]
== REQUESTSTATUS
Request the status of an already submitted asynchronous CoreAdmin API call.
@@ -326,7 +322,7 @@ The call below will return the status of an already submitted asynchronous CoreA
[source,bash]
http://localhost:8983/solr/admin/cores?action=REQUESTSTATUS&requestid=1
-[[CoreAdminAPI-REQUESTRECOVERY]]
+[[coreadmin-requestrecovery]]
== REQUESTRECOVERY
The `REQUESTRECOVERY` action manually asks a core to recover by synching with the leader. This should be considered an "expert" level command and should be used in situations where the node (SorlCloud replica) is unable to become active automatically.
@@ -338,7 +334,6 @@ The `REQUESTRECOVERY` action manually asks a core to recover by synching with th
`core`::
The name of the core to re-sync. This parameter is required.
-[[CoreAdminAPI-Examples.1]]
=== REQUESTRECOVERY Examples
[source,bash]