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.
reindex= true or false false Works on a datacenter level. Run once per Solr-enabled datacenter.
  • true - reindexes the data.
  • false - does not reindex the data.
deleteAll= true or false false
  • true - deletes the already existing index before reindexing; search results will return either no or partial data while the index is rebuilding.
  • false - does not delete the existing index, causing the reindex to happen in-place; search results will return partially incorrect results while the index is updating.
Note: To reload the core and prevent reindexing, accept the default values reindex=false and deleteAll=false.

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 reindex, which includes deleting all the old data, of the Solr data is required. In these cases, anything less than a full reindex renders the schema changes ineffective. Typically, a change to the Solr schema requires a full reindexing.

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.

Reindexing in place

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

Reindexing in full

Setting reindex=true and deleteAll=true deletes the Lucene index and reindexes the dataset. User searches initially return no or partial documents as the Solr cores reload and data is reindexed.
dsetool reload_core keyspace.table reindex=true deleteAll=true

During reindexing, a series of criteria routes sub-queries to the nodes most capable of handling them. See Shard routing for distributed queries.

Verifying indexing status

See Checking the indexing status using dsetool.