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> ...]
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.
Re-indexing in place
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
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.