solr/solr-ref-guide/src/coreadmin-api.adoc - lucene-solr - Git at Google

 = CoreAdmin API
 :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
 // regarding copyright ownership.  The ASF licenses this file
 // to you under the Apache License, Version 2.0 (the
 // "License"); you may not use this file except in compliance
 // with the License.  You may obtain a copy of the License at
 //
 //   http://www.apache.org/licenses/LICENSE-2.0
 //
 // Unless required by applicable law or agreed to in writing,
 // software distributed under the License is distributed on an
 // "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
 // KIND, either express or implied.  See the License for the
 // specific language governing permissions and limitations
 // under the License.

 The Core Admin API is primarily used under the covers by the <<collections-api.adoc#,Collections API>> when running a <<solrcloud.adoc#,SolrCloud>> cluster.

 SolrCloud users should not typically use the CoreAdmin API directly, but the API may be useful for users of single-node or leader/follower Solr installations for core maintenance operations.

 The CoreAdmin API is implemented by the CoreAdminHandler, which is a special purpose <<requesthandlers-and-searchcomponents-in-solrconfig.adoc#,request handler>> that is used to manage Solr cores. Unlike other request handlers, the CoreAdminHandler is not attached to a single core. Instead, there is a single instance of the CoreAdminHandler in each Solr node that manages all the cores running in that node and is accessible at the `/solr/admin/cores` path.

 CoreAdmin actions can be executed by via HTTP requests that specify an `action` request parameter, with additional action specific arguments provided as additional parameters.

 All action names are uppercase, and are defined in depth in the sections below.

 [[coreadmin-status]]
 == STATUS

 The `STATUS` action returns the status of all running Solr cores, or status for only the named core.

 `admin/cores?action=STATUS&core=_core-name_`

 === STATUS Parameters

 `core`::
 The name of a core, as listed in the "name" attribute of a `<core>` element in `solr.xml`.

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

 [[coreadmin-create]]
 == CREATE

 The `CREATE` action creates a new core and registers it.

 If a Solr core with the given name already exists, it will continue to handle requests while the new core is initializing. When the new core is ready, it will take new requests and the old core will be unloaded.

 `admin/cores?action=CREATE&name=_core-name_&instanceDir=_path/to/dir_&config=solrconfig.xml&dataDir=data`

 Note that this command is the only one of the Core Admin API commands that *does not* support the `core` parameter. Instead, the `name` parameter is required, as shown below.

 .CREATE must be able to find a configuration!
 [WARNING]
 ====
 Your CREATE call must be able to find a configuration, or it will not succeed.

 When you are running SolrCloud and create a new core for a collection, the configuration will be inherited from the collection. Each collection is linked to a configName, which is stored in ZooKeeper. This satisfies the configuration requirement. There is something to note, though: if you're running SolrCloud, you should *NOT* use the CoreAdmin API at all. Use the <<collections-api.adoc#,Collections API>>.

 When you are not running SolrCloud, if you have <<config-sets.adoc#,Configsets>> defined, you can use the `configSet` parameter as documented below. If there are no configsets, then the `instanceDir` specified in the CREATE call must already exist, and it must contain a `conf` directory which in turn must contain `solrconfig.xml`, your schema (usually named either `managed-schema` or `schema.xml`), and any files referenced by those configs.

 The config and schema filenames can be specified with the `config` and `schema` parameters, but these are expert options. One thing you could do to avoid creating the `conf` directory is use `config` and `schema` parameters that point at absolute paths, but this can lead to confusing configurations unless you fully understand what you are doing.
 ====

 .CREATE and the `core.properties` file
 [IMPORTANT]
 ====
 The `core.properties` file is built as part of the CREATE command. If you create a `core.properties` file yourself in a core directory and then try to use CREATE to add that core to Solr, you will get an error telling you that another core is already defined there. The `core.properties` file must NOT exist before calling the CoreAdmin API with the CREATE command.
 ====

 === CREATE Core Parameters

 `name`::
 The name of the new core. Same as `name` on the `<core>` element. This parameter is required.

 `instanceDir`::
 The directory where files for this core should be stored. Same as `instanceDir` on the `<core>` element. The default is the value specified for the `name` parameter if not supplied. This directory must be inside `SOLR_HOME`, `SOLR_DATA_HOME` or one of the paths specified by system property `solr.allowPaths`.

 `config`::
 Name of the config file (i.e., `solrconfig.xml`) relative to `instanceDir`.

 `schema`::
 Name of the schema file to use for the core. Please note that if you are using a "managed schema" (the default behavior) then any value for this property which does not match the effective `managedSchemaResourceName` will be read once, backed up, and converted for managed schema use. See <<schema-factory-definition-in-solrconfig.adoc#,Schema Factory Definition in SolrConfig>> for details.

 `dataDir`::
 Name of the data directory relative to `instanceDir`. If absolute value is used, it must be inside `SOLR_HOME`, `SOLR_DATA_HOME` or one of the paths specified by system property `solr.allowPaths`.

 `configSet`::
 Name of the configset to use for this core. For more information, see the section <<config-sets.adoc#,Configsets>>.

 `collection`::
 The name of the collection to which this core belongs. The default is the name of the core. `collection._param_=_value_` causes a property of `_param_=_value_` to be set if a new collection is being created. Use `collection.configName=_config-name_` to point to the configuration for a new collection.
 +
 WARNING: While it's possible to create a core for a non-existent collection, this approach is not supported and not recommended. Always create a collection using the <<collections-api.adoc#,Collections API>> before creating a core directly for it.

 `shard`::
 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#defining-core-properties-files,core.properties file contents>>.

 `async`::
 Request ID to track this action which will be processed asynchronously.

 Use `collection.configName=_configname_` to point to the config for a new collection.

 === CREATE Example

 [source,bash]
 http://localhost:8983/solr/admin/cores?action=CREATE&name=my_core&collection=my_collection&shard=shard2


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

 `admin/cores?action=RELOAD&core=_core-name_`

 This is useful when you've made changes to a Solr core's configuration on disk, such as adding new field definitions. Calling the RELOAD action lets you apply the new configuration without having to restart Solr.

 [IMPORTANT]
 ====
 RELOAD performs "live" reloads of SolrCore, reusing some existing objects. Some configuration options, such as the `dataDir` location and `IndexWriter`-related settings in `solrconfig.xml` can not be changed and made active with a simple RELOAD action.
 ====

 === RELOAD Core Parameters

 `core`::
 The name of the core, as listed in the "name" attribute of a `<core>` element in `solr.xml`. This parameter is required.

 [[coreadmin-rename]]
 == RENAME

 The `RENAME` action changes the name of a Solr core.

 `admin/cores?action=RENAME&core=_core-name_&other=_other-core-name_`

 === RENAME Parameters

 `core`::
 The name of the Solr core to be renamed. This parameter is required.

 `other`::
 The new name for the Solr core. If the persistent attribute of `<solr>` is `true`, the new name will be written to `solr.xml` as the `name` attribute of the `<core>` attribute. This parameter is required.

 `async`::
 Request ID to track this action which will be processed asynchronously.


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

 `admin/cores?action=SWAP&core=_core-name_&other=_other-core-name_`

 [IMPORTANT]
 ====
 Do not use `SWAP` with a SolrCloud node. It is not supported and can result in the core being unusable.
 ====

 === SWAP Parameters

 `core`::
 The name of one of the cores to be swapped. This parameter is required.

 `other`::
 The name of one of the cores to be swapped. This parameter is required.

 `async`::
 Request ID to track this action which will be processed asynchronously.


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

 `admin/cores?action=UNLOAD&core=_core-name_`

 The `UNLOAD` action requires a parameter (`core`) identifying the core to be removed. If the persistent attribute of `<solr>` is set to `true`, the `<core>` element with this `name` attribute will be removed from `solr.xml`.

 [IMPORTANT]
 ====
 Unloading all cores in a SolrCloud collection causes the removal of that collection's metadata from ZooKeeper.
 ====

 === UNLOAD Parameters

 `core`::
 The name of a core to be removed. This parameter is required.

 `deleteIndex`::
 If `true`, will remove the index when unloading the core. The default is `false`.

 `deleteDataDir`::
 If `true`, removes the `data` directory and all sub-directories. The default is `false`.

 `deleteInstanceDir`::
 If `true`, removes everything related to the core, including the index directory, configuration files and other related files. The default is `false`.

 `async`::
 Request ID to track this action which will be processed asynchronously.

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

 `admin/cores?action=MERGEINDEXES&core=_new-core-name_&indexDir=_path/to/core1/data/index_&indexDir=_path/to/core2/data/index_`

 In this example, we use the `indexDir` parameter to define the index locations of the source cores. The `core` parameter defines the target index. A benefit of this approach is that we can merge any Lucene-based index that may not be associated with a Solr core.

 Alternatively, we can instead use a `srcCore` parameter, as in this example:

 `admin/cores?action=mergeindexes&core=_new-core-name_&srcCore=_core1-name_&srcCore=_core2-name_`

 This approach allows us to define cores that may not have an index path that is on the same physical server as the target core. However, we can only use Solr cores as the source indexes. Another benefit of this approach is that we don't have as high a risk for corruption if writes occur in parallel with the source index.

 We can make this call run asynchronously by specifying the `async` parameter and passing a request-id. This id can then be used to check the status of the already submitted task using the REQUESTSTATUS API.

 === MERGEINDEXES Parameters

 `core`::
 The name of the target core/index. This parameter is required.

 `indexDir`::
 Multi-valued, directories that would be merged.

 `srcCore`::
 Multi-valued, source cores that would be merged.

 `async`::
 Request ID to track this action which will be processed asynchronously.


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

 The `SPLIT` action supports five parameters, which are described in the table below.

 === SPLIT Parameters

 `core`::
 The name of the core to be split. This parameter is required.

 `path`::
 Multi-valued, the directory path in which a piece of the index will be written. Either this parameter or `targetCore` must be specified. If this is specified, the `targetCore` parameter may not be used.

 `targetCore`::
 Multi-valued, the target Solr core to which a piece of the index will be merged. Either this parameter or `path` must be specified. If this is specified, the `path` parameter may not be used.

 `ranges`::
 A comma-separated list of hash ranges in hexadecimal format. If this parameter is used, `split.key` should not be. See the <<SPLIT Examples>> below for an example of how this parameter can be used.

 `split.key`::
 The key to be used for splitting the index. If this parameter is used, `ranges` should not be. See the <<SPLIT Examples>> below for an example of how this parameter can be used.

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

 *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*:

 [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*:

 [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*:

 [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

 This example uses the `ranges` parameter with hash ranges 0-500, 501-1000 and 1001-1500 specified in hexadecimal. Here the index will be split into three pieces with each targetCore receiving documents matching the hash ranges specified i.e., core1 will get documents with hash range 0-500, core2 will receive documents with hash range 501-1000 and finally, core3 will receive documents with hash range 1001-1500. At least one hash range must be specified. Please note that using a single hash range equal to a route key's hash range is NOT equivalent to using the `split.key` parameter because multiple route keys can hash to the same range.

 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 <<shard-management.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.

 [[coreadmin-requeststatus]]
 == REQUESTSTATUS

 Request the status of an already submitted asynchronous CoreAdmin API call.

 `admin/cores?action=REQUESTSTATUS&requestid=_id_`

 === Core REQUESTSTATUS Parameters

 The REQUESTSTATUS command has only one parameter.

 `requestid`::
 The user defined request-id for the asynchronous request. This parameter is required.

 The call below will return the status of an already submitted asynchronous CoreAdmin call.

 [source,bash]
 http://localhost:8983/solr/admin/cores?action=REQUESTSTATUS&requestid=1

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

 `admin/cores?action=REQUESTRECOVERY&core=_core-name_`

 === REQUESTRECOVERY Parameters

 `core`::
 The name of the core to re-sync. This parameter is required.

 === REQUESTRECOVERY Examples

 [source,bash]
 http://localhost:8981/solr/admin/cores?action=REQUESTRECOVERY&core=gettingstarted_shard1_replica1

 The core to specify can be found by expanding the appropriate ZooKeeper node via the admin UI.
	= CoreAdmin API
	: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
	// regarding copyright ownership. The ASF licenses this file
	// to you under the Apache License, Version 2.0 (the
	// "License"); you may not use this file except in compliance
	// with the License. You may obtain a copy of the License at
	//
	// http://www.apache.org/licenses/LICENSE-2.0
	//
	// Unless required by applicable law or agreed to in writing,
	// software distributed under the License is distributed on an
	// "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
	// KIND, either express or implied. See the License for the
	// specific language governing permissions and limitations
	// under the License.

	The Core Admin API is primarily used under the covers by the <<collections-api.adoc#,Collections API>> when running a <<solrcloud.adoc#,SolrCloud>> cluster.

	SolrCloud users should not typically use the CoreAdmin API directly, but the API may be useful for users of single-node or leader/follower Solr installations for core maintenance operations.

	The CoreAdmin API is implemented by the CoreAdminHandler, which is a special purpose <<requesthandlers-and-searchcomponents-in-solrconfig.adoc#,request handler>> that is used to manage Solr cores. Unlike other request handlers, the CoreAdminHandler is not attached to a single core. Instead, there is a single instance of the CoreAdminHandler in each Solr node that manages all the cores running in that node and is accessible at the `/solr/admin/cores` path.

	CoreAdmin actions can be executed by via HTTP requests that specify an `action` request parameter, with additional action specific arguments provided as additional parameters.

	All action names are uppercase, and are defined in depth in the sections below.

	[[coreadmin-status]]
	== STATUS

	The `STATUS` action returns the status of all running Solr cores, or status for only the named core.

	`admin/cores?action=STATUS&core=_core-name_`

	=== STATUS Parameters

	`core`::
	The name of a core, as listed in the "name" attribute of a `<core>` element in `solr.xml`.

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

	[[coreadmin-create]]
	== CREATE

	The `CREATE` action creates a new core and registers it.

	If a Solr core with the given name already exists, it will continue to handle requests while the new core is initializing. When the new core is ready, it will take new requests and the old core will be unloaded.

	`admin/cores?action=CREATE&name=_core-name_&instanceDir=_path/to/dir_&config=solrconfig.xml&dataDir=data`

	Note that this command is the only one of the Core Admin API commands that does not support the `core` parameter. Instead, the `name` parameter is required, as shown below.

	.CREATE must be able to find a configuration!
	[WARNING]
	====
	Your CREATE call must be able to find a configuration, or it will not succeed.

	When you are running SolrCloud and create a new core for a collection, the configuration will be inherited from the collection. Each collection is linked to a configName, which is stored in ZooKeeper. This satisfies the configuration requirement. There is something to note, though: if you're running SolrCloud, you should NOT use the CoreAdmin API at all. Use the <<collections-api.adoc#,Collections API>>.

	When you are not running SolrCloud, if you have <<config-sets.adoc#,Configsets>> defined, you can use the `configSet` parameter as documented below. If there are no configsets, then the `instanceDir` specified in the CREATE call must already exist, and it must contain a `conf` directory which in turn must contain `solrconfig.xml`, your schema (usually named either `managed-schema` or `schema.xml`), and any files referenced by those configs.

	The config and schema filenames can be specified with the `config` and `schema` parameters, but these are expert options. One thing you could do to avoid creating the `conf` directory is use `config` and `schema` parameters that point at absolute paths, but this can lead to confusing configurations unless you fully understand what you are doing.
	====

	.CREATE and the `core.properties` file
	[IMPORTANT]
	====
	The `core.properties` file is built as part of the CREATE command. If you create a `core.properties` file yourself in a core directory and then try to use CREATE to add that core to Solr, you will get an error telling you that another core is already defined there. The `core.properties` file must NOT exist before calling the CoreAdmin API with the CREATE command.
	====

	=== CREATE Core Parameters

	`name`::
	The name of the new core. Same as `name` on the `<core>` element. This parameter is required.

	`instanceDir`::
	The directory where files for this core should be stored. Same as `instanceDir` on the `<core>` element. The default is the value specified for the `name` parameter if not supplied. This directory must be inside `SOLR_HOME`, `SOLR_DATA_HOME` or one of the paths specified by system property `solr.allowPaths`.

	`config`::
	Name of the config file (i.e., `solrconfig.xml`) relative to `instanceDir`.

	`schema`::
	Name of the schema file to use for the core. Please note that if you are using a "managed schema" (the default behavior) then any value for this property which does not match the effective `managedSchemaResourceName` will be read once, backed up, and converted for managed schema use. See <<schema-factory-definition-in-solrconfig.adoc#,Schema Factory Definition in SolrConfig>> for details.

	`dataDir`::
	Name of the data directory relative to `instanceDir`. If absolute value is used, it must be inside `SOLR_HOME`, `SOLR_DATA_HOME` or one of the paths specified by system property `solr.allowPaths`.

	`configSet`::
	Name of the configset to use for this core. For more information, see the section <<config-sets.adoc#,Configsets>>.

	`collection`::
	The name of the collection to which this core belongs. The default is the name of the core. `collection._param_=_value_` causes a property of `_param_=_value_` to be set if a new collection is being created. Use `collection.configName=_config-name_` to point to the configuration for a new collection.
	+
	WARNING: While it's possible to create a core for a non-existent collection, this approach is not supported and not recommended. Always create a collection using the <<collections-api.adoc#,Collections API>> before creating a core directly for it.

	`shard`::
	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#defining-core-properties-files,core.properties file contents>>.

	`async`::
	Request ID to track this action which will be processed asynchronously.

	Use `collection.configName=_configname_` to point to the config for a new collection.

	=== CREATE Example

	[source,bash]
	http://localhost:8983/solr/admin/cores?action=CREATE&name=my_core&collection=my_collection&shard=shard2


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

	`admin/cores?action=RELOAD&core=_core-name_`

	This is useful when you've made changes to a Solr core's configuration on disk, such as adding new field definitions. Calling the RELOAD action lets you apply the new configuration without having to restart Solr.

	[IMPORTANT]
	====
	RELOAD performs "live" reloads of SolrCore, reusing some existing objects. Some configuration options, such as the `dataDir` location and `IndexWriter`-related settings in `solrconfig.xml` can not be changed and made active with a simple RELOAD action.
	====

	=== RELOAD Core Parameters

	`core`::
	The name of the core, as listed in the "name" attribute of a `<core>` element in `solr.xml`. This parameter is required.

	[[coreadmin-rename]]
	== RENAME

	The `RENAME` action changes the name of a Solr core.

	`admin/cores?action=RENAME&core=_core-name_&other=_other-core-name_`

	=== RENAME Parameters

	`core`::
	The name of the Solr core to be renamed. This parameter is required.

	`other`::
	The new name for the Solr core. If the persistent attribute of `<solr>` is `true`, the new name will be written to `solr.xml` as the `name` attribute of the `<core>` attribute. This parameter is required.

	`async`::
	Request ID to track this action which will be processed asynchronously.


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

	`admin/cores?action=SWAP&core=_core-name_&other=_other-core-name_`

	[IMPORTANT]
	====
	Do not use `SWAP` with a SolrCloud node. It is not supported and can result in the core being unusable.
	====

	=== SWAP Parameters

	`core`::
	The name of one of the cores to be swapped. This parameter is required.

	`other`::
	The name of one of the cores to be swapped. This parameter is required.

	`async`::
	Request ID to track this action which will be processed asynchronously.


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

	`admin/cores?action=UNLOAD&core=_core-name_`

	The `UNLOAD` action requires a parameter (`core`) identifying the core to be removed. If the persistent attribute of `<solr>` is set to `true`, the `<core>` element with this `name` attribute will be removed from `solr.xml`.

	[IMPORTANT]
	====
	Unloading all cores in a SolrCloud collection causes the removal of that collection's metadata from ZooKeeper.
	====

	=== UNLOAD Parameters

	`core`::
	The name of a core to be removed. This parameter is required.

	`deleteIndex`::
	If `true`, will remove the index when unloading the core. The default is `false`.

	`deleteDataDir`::
	If `true`, removes the `data` directory and all sub-directories. The default is `false`.

	`deleteInstanceDir`::
	If `true`, removes everything related to the core, including the index directory, configuration files and other related files. The default is `false`.

	`async`::
	Request ID to track this action which will be processed asynchronously.

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

	`admin/cores?action=MERGEINDEXES&core=_new-core-name_&indexDir=_path/to/core1/data/index_&indexDir=_path/to/core2/data/index_`

	In this example, we use the `indexDir` parameter to define the index locations of the source cores. The `core` parameter defines the target index. A benefit of this approach is that we can merge any Lucene-based index that may not be associated with a Solr core.

	Alternatively, we can instead use a `srcCore` parameter, as in this example:

	`admin/cores?action=mergeindexes&core=_new-core-name_&srcCore=_core1-name_&srcCore=_core2-name_`

	This approach allows us to define cores that may not have an index path that is on the same physical server as the target core. However, we can only use Solr cores as the source indexes. Another benefit of this approach is that we don't have as high a risk for corruption if writes occur in parallel with the source index.

	We can make this call run asynchronously by specifying the `async` parameter and passing a request-id. This id can then be used to check the status of the already submitted task using the REQUESTSTATUS API.

	=== MERGEINDEXES Parameters

	`core`::
	The name of the target core/index. This parameter is required.

	`indexDir`::
	Multi-valued, directories that would be merged.

	`srcCore`::
	Multi-valued, source cores that would be merged.

	`async`::
	Request ID to track this action which will be processed asynchronously.


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

	The `SPLIT` action supports five parameters, which are described in the table below.

	=== SPLIT Parameters

	`core`::
	The name of the core to be split. This parameter is required.

	`path`::
	Multi-valued, the directory path in which a piece of the index will be written. Either this parameter or `targetCore` must be specified. If this is specified, the `targetCore` parameter may not be used.

	`targetCore`::
	Multi-valued, the target Solr core to which a piece of the index will be merged. Either this parameter or `path` must be specified. If this is specified, the `path` parameter may not be used.

	`ranges`::
	A comma-separated list of hash ranges in hexadecimal format. If this parameter is used, `split.key` should not be. See the <<SPLIT Examples>> below for an example of how this parameter can be used.

	`split.key`::
	The key to be used for splitting the index. If this parameter is used, `ranges` should not be. See the <<SPLIT Examples>> below for an example of how this parameter can be used.

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

	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:

	[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:

	[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:

	[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

	This example uses the `ranges` parameter with hash ranges 0-500, 501-1000 and 1001-1500 specified in hexadecimal. Here the index will be split into three pieces with each targetCore receiving documents matching the hash ranges specified i.e., core1 will get documents with hash range 0-500, core2 will receive documents with hash range 501-1000 and finally, core3 will receive documents with hash range 1001-1500. At least one hash range must be specified. Please note that using a single hash range equal to a route key's hash range is NOT equivalent to using the `split.key` parameter because multiple route keys can hash to the same range.

	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 <<shard-management.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.

	[[coreadmin-requeststatus]]
	== REQUESTSTATUS

	Request the status of an already submitted asynchronous CoreAdmin API call.

	`admin/cores?action=REQUESTSTATUS&requestid=_id_`

	=== Core REQUESTSTATUS Parameters

	The REQUESTSTATUS command has only one parameter.

	`requestid`::
	The user defined request-id for the asynchronous request. This parameter is required.

	The call below will return the status of an already submitted asynchronous CoreAdmin call.

	[source,bash]
	http://localhost:8983/solr/admin/cores?action=REQUESTSTATUS&requestid=1

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

	`admin/cores?action=REQUESTRECOVERY&core=_core-name_`

	=== REQUESTRECOVERY Parameters

	`core`::
	The name of the core to re-sync. This parameter is required.

	=== REQUESTRECOVERY Examples

	[source,bash]
	http://localhost:8981/solr/admin/cores?action=REQUESTRECOVERY&core=gettingstarted_shard1_replica1

	The core to specify can be found by expanding the appropriate ZooKeeper node via the admin UI.