CoreAdmin API

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

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.

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 the Web container.

The RENAME action changes the name of a Solr core.

admin/cores?action=RENAME&core=core-name&other=other-core-name

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

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.

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.

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.

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

admin/cores?action=REQUESTSTATUS&requestid=id

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