CoreAdminHandler Parameters and Usage

  categories:搜索资料  tags:,   author:

The CoreAdminHandler is a special SolrRequestHandler that is used to manage Solr cores. Unlike normal SolrRequestHandlers, the CoreAdminHandler is not attached to a single core. Instead, it manages all the cores running in a single Solr instance. Only one CoreAdminHandler exists for each top-level Solr instance.

To use the CoreAdminHandler, make sure that the adminPath attribute is defined on the <cores> element; otherwise you will not be able to make HTTP requests to perform Solr core administration.

The CoreAdminHandler supports seven different actions that may be invoked on the adminPath URL. The action to perform is named by the HTTP request parameter “action”, with arguments for a specific action being provided as additional parameters.

All action names are uppercase. The action names are:

  • SWAP

These actions are described in detail in the sections below.


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



The STATUS action accepts one optional parameter:

Parameter Description
core (Optional) 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 CREATE action creates a new core and registers it. If persistence is enabled (persistent="true" on the <solr> element), the updated configuration for this new core will be saved in solr.xml. 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.


The CREATE accepts the two mandatory parameters, as well as five optional parameters.

Parameter Description
name The name of the new core. Same as “name” on the <core> element.
instanceDir The directory where files for this SolrCore should be stored. Same as instanceDir on the <core> element.
config (Optional) Name of the config file (solrconfig.xml) relative to instanceDir.
schema (Optional) Name of the schema file (schema.xml) relative to instanceDir.
datadir (Optional) Name of the data directory relative to instanceDir.
collection (Optional) 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=<configname> to point to the configuration for a new collection.
shard (Optional) The shard id this core represents. Normally you want to be auto-assigned a shard id.

Use collection.configName=<configname> to point to the config for a new collection.

For example: curl 'http://localhost:8983/solr/admin/cores?action=CREATE&name=mycore&collection=collection1&shard=shard2'


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.

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 the Web container.  However the Core Container does not persist the SolrCloud solr.xml parameters, such as solr/@zkHost and solr/cores/@hostPort, which are ignored.


The RELOAD action accepts a single parameter, core, which is the name of the core to be reloaded.

As of Solr 4.0, REALOAD 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.


The RENAME action changes the name of a Solr core.


The RENAME action requires the following two parameter:

Parameter Description
core The name of the Solr core to be renamed.
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.


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.


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

The SWAP action requires two parameters, which are described in the table below.

Parameter Description
core The name of one of the cores to be swapped.
other The name of one of the cores to be swapped.


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.


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.

Unloading all cores in a SolrCloud collection causes the removal of that collection’s metadata from ZooKeeper.

There are three parameters that can be used with the UNLOAD action:

  • deleteIndex: if true, will remove the index when unloading the core.
  • deleteDataDir: if true, removes the data directory and all sub-directories.
  • deleteInstanceDir: if true, removes everything related to the core, including the index directory, configuration files, and other related files.


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.


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:


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.


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 three parameters, which are described in the table below.

Parameter Description Multi-valued
core The name of the core to be split. false
path The directory path in which a piece of the index will be written. true
targetCore The target Solr core to which a piece of the index will be merged true
Either path or targetCore parameter must be specified but not both.

The core index will be split into as many pieces as the number of path or targetCore parameters.


This example shows the usage of this action with two targetCore parameters. Here the core index will be split into two pieces and merged into the two targetCore indexes.


This example shows the usage of this action with two path parameters. The core index will be split into two pieces and written into the two directory paths specified.

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 SPLITSHARD command but it can be used for non-cloud Solr cores as well. When used against a non-cloud core, this action will split the source index and distribute its documents alternately so that each split piece contains an equal number of documents.


Moving to the New solr.xml Format Solr Cores and solr.xml

快乐成长 每天进步一点点      京ICP备18032580号-1