Reloading a Solr core using dsetool

After you modify schema.xml or solrconfig.xml or upload resource files (like a synonym file, reload a Solr core instead of creating a new one.

After you modify schema.xml or solrconfig.xml or upload resource files (like a synonym file), reload a Solr core instead of creating a new one.

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= filepath n/a Path of the schema file
solrconfig= filepath n/a Path of the solrconfig.xml file
distributed= true or false true
  • true distributes and applies the reload operation to all nodes in the local DC.
  • false applies the reload operation only to the node it was sent to.
deleteAll= true or false false
  • true deletes the already existing index before re-indexing; search results will return either no or partial data while the index is rebuilding.
  • false does not delete the existing index, causing the re-index to happen in-place; search results will return partially incorrect results while the index is updating. Keep the current index (accepting reads) while you build the new one, then swap over to the new index after it's ready.
reindex= true or false false Reindex works on a datacenter (DC) level. Run this command once per Solr enabled DC.
  • true re-indexes the data.
  • false does not re-index the data.
Note: To reload the core and prevent re-indexing, accept the default values reindex=false and deleteAll=false.
This command preserves the case of keyspace and table names. You must use the correct case for the keyspace and table names.

None of these options is mandatory. If the schema.xml or solrconfig.xml, 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 be incompatible. Changes to a field's type can 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 only on those failing nodes using distributed=false.

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