Reindexing

Schema Changes

With very few exceptions, changes to a collection’s schema require reindexing. This is because many of the available options are only applied during the indexing process. Solr has no way to implement the desired change without reindexing the data.

To understand the general reason why reindexing is ever required, it’s helpful to understand the relationship between Solr’s schema and the underlying Lucene index. Lucene does not use a schema, schemas a Solr-only concept. When you change Solr’s schema, the Lucene index is not modified in any way.

This means that there are many types of schema changes that cannot be reflected in the index simply by modifying Solr’s schema. This is different from most database models where schemas are used. When indexing, Solr’s schema acts like a rulebook for indexing documents by telling Lucene how to interpret the data being sent. Once the documents are in Lucene, Solr’s schema has no control over the underlying data structure.

In addition, changing the schema version property is equivalent to changing field type properties. This type of change is usually only made during or because of a major upgrade.

Solrconfig Changes

Identifying changes to solrconfig.xml that alter how data is ingested and thus require reindexing is less straightforward. The general rule is "anything that changes what gets stored in the index requires reindexing". Here are several known examples.

The parameter luceneMatchVersion in solrconfig.xml controls the compatibility of Solr with Lucene. Since this parameter can change the rules for analysis behind the scenes, it’s always recommended to reindex when changing it. Usually this is only changed in conjunction with a major upgrade.

If you make a change to Solr’s Update Request Processors, it’s generally because you want to change something about how update requests (documents) are processed (indexed). In this case, we recommend that you reindex your documents to implement the changes you’ve made just as if you had changed the schema.

Similarly, if you change the codecFactory parameter in solrconfig.xml, it is again strongly recommended that you plan to reindex your documents to avoid unintended behavior.

Delete All Documents

The best approach is to first delete everything from the index, and then index your data again. You can delete all documents with a "delete-by-query", such as this:

curl -X POST -H 'Content-Type: application/json' --data-binary '{"delete":{"query":"*:*" }}' http://localhost:8983/solr/my_collection/update

It’s important to verify that all documents have been deleted, as that ensures the Lucene index segments have been deleted as well.

To verify that there are no segments in your index, look in the data/index directory and confirm it has no segments files. Since the data directory can be customized, see the section Specifying a Location for Index Data with the dataDir Parameter for the location of your index files.

Note you will need to verify the indexes have been removed in every shard and every replica on every node of a cluster. It is not sufficient to only query for the number of documents because you may have no documents but still have index segments.

Once the indexes have been cleared, you can start reindexing by re-running the original index process.

Index to Another Collection

Another approach is to use index to a new collection and use Solr’s collection alias feature to seamlessly point the application to a new collection without downtime.

This option is only available for Solr installations running in SolrCloud mode.

With this approach, you will index your documents into a new collection that uses your changes and, once indexing and testing are complete, create an alias that points your front-end at the new collection. From that point, new queries and updates will be routed to the new collection seamlessly.

Once the alias is in place and you are satisfied you no longer need the old data, you can delete the old collection with the Collections API DELETE command.