Reloading a Solr core using dsetool

After you modify schema.xml or solrconfig.xml, reload a Solr core instead of creating a new one. Do not make schema changes on production systems.

Reload a Solr core instead of creating a new one after you modify the schema.xml or solrconfig.xml. Changes apply only to the node where you reload the core. Do not make schema changes on production systems.

To simplify Solr code reloading, use dsetool reload_core. The syntax of the command is:

$ dsetool reload_core <keyspace>.<table> [<option> ...]
where <option> is one or more of the following options:
Option Settings Default Description
schema= <path> n/a Path of the schema file used for reloading the core
solrconfig= <path> n/a Path of the solrconfig file used for reloading the core
distributed= true or false true true distributes an index to nodes in the cluster. false re-indexes the Solr data on one node. The false setting is used in certain recovery and upgrade procedures. Applies only to the node where you reload the core.
reindex= true or false false true re-indexes the data. false deletes any existing Lucene index and indexes the data for the first time. Applies only to the node where you reload the core.
deleteAll= true or false false Setting reindex=true and deleteAll=true re-indexes data in place or re-indexes in full. Accepting the defaults reloads the core and no re-indexing occurs. Setting reindex=true and deleteAll=false re-indexes data but keeps the existing Lucene index, causing user searches to yield inaccurate results. Applies only to the node where you reload the core.

None of these options is mandatory. If the solrconfig or schema, or both, are provided, DataStax Enterprise uploads the files before reloading the core. You use these options, described in "Creating a core with automatic resource generation", the same way with the dsetool command or with an HTTP RELOAD request.

When you make a change to the schema, the compatibility of the existing index and the new schema is questionable. If the change to the schema made changes to a field's type, the index and schema will certainly be incompatible. Changes to a field's type can actually occur in subtle ways, occasionally without a change to the schema.xml file itself. For example, a change to other configuration files, such as synonyms, can change the schema. If such an incompatibility exists, a full re-index, which includes deleting all the old data, of the Solr data is required. In these cases, anything less than a full re-index renders the schema changes ineffective. Typically, a change to the Solr schema requires a full re-indexing.

Note: If one or more nodes fail to reload the core in distributed operations, an error message indicates a list of the failing node or nodes. Issue the reload again.

Re-indexing in place

Setting reindex=true and deleteAll=false re-indexes data and keeps the existing lucene index. During the uploading process, user searches yield inaccurate results. To perform an in-place re-index, use this syntax:
$ dsetool reload_core keyspace.table reindex=true deleteAll=false

Re-indexing in full

Setting reindex=true and deleteAll=true deletes the Lucene index and re-indexes the dataset. User searches initially return no documents as the Solr cores reload and data is re-indexed.
$ dsetool reload_core keyspace.table reindex=true deleteAll=true

Verifying indexing status

Use the Solr Admin to check the indexing status.