lucene-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hoss Man (Confluence)" <>
Subject [CONF] Apache Solr Reference Guide > CoreAdminHandler Parameters and Usage
Date Wed, 24 Jul 2013 00:12:00 GMT
Space: Apache Solr Reference Guide (
Page: CoreAdminHandler Parameters and Usage (

Change Comment:
scrollbar & removal of h1

Edited by Hoss Man:

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|#{{SWAP}}]

These actions are described in detail in the sections below.

h2. {{STATUS}}

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.

h2. {{CREATE}}

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'}}

h2. {{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.

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.&nbsp; 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

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.

h2. {{RENAME}}

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

h2. {{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.


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

h2. {{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.


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.


Stop watching space:
Change email notification preferences:


View raw message