Reload a Solr core instead of creating a new one when you modify the schema.xml or solrconfig.xml.
You can use options with the RELOAD command to re-index and keep or delete the Lucene index.
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.
Use these RELOAD command options to specify the level of re-indexing that occurs:
True, the default, distributes an index to nodes in the cluster. False re-indexes the Solr data on one node.
curl -v "http://localhost:8983/solr/admin/cores?action=RELOAD& name=<keyspace.table>&distributed=true"
reindex and deleteAll
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:
curl "http://localhost:8983/solr/admin/cores?action=RELOAD &name=<keyspace.table>&reindex=true&deleteAll=false"
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.
Setting reindex=false and deleteAll=true does nothing.
You can re-index manually using the UI or command-line tools. In the Core Admin screen of the Solr Admin UI, the Reload, Reindex and Full Reindex buttons perform functions that correspond to RELOAD command options.
If you HTTP post the files to a pre-existing table, DSE Search starts indexing the data. If you HTTP post the files to a non-existent column keyspace or table, DSE Search creates the keyspace and table, and then starts indexing the data. For example, you can change the stopwords.txt file, repost the schema, and the index updates.
To check the indexing status, open the Solr Admin and click Core Admin.
You can also check the logs to get the indexing status. For example, you can check information about the plugin initializer:
INDEXING / REINDEXING - INFO SolrSecondaryIndex plugin initializer. 2013-08-26 19:25:43,347 SolrSecondaryIndex.java (line 403) Reindexing 439171 keys for core wiki.solr
Or you can check the SecondaryIndexManager.java information:
INFO Thread-38 2013-08-26 19:31:28,498 SecondaryIndexManager.java (line 136) Submitting index build of wiki.solr for data in SSTableReader(path='/mnt/cassandra/data/wiki/solr/wiki-solr-ic-5-Data.db'), SSTableReader(path='/mnt/cassandra/data/wiki/solr/wiki-solr-ic-6-Data.db') FINISH INDEXING - INFO Thread-38 2013-08-26 19:38:10,701 SecondaryIndexManager.java (line 156) Index build of wiki.solr complete
DSE Search includes a REST API for viewing and adding resources associated with an index. You can look at the contents of the existing Solr resource by loading its URL in a web browser or using HTTP get. Retrieving and viewing resources returns the last uploaded resource, even if the resource is not the one currently in use. If you upload a new schema, and then before reloading, request the schema resource, Solr returns the new schema even though the core continues to use the old schema.
Use this format:
Generally, you can post any resource required by Solr to this URL. For example, stopwords.txt and elevate.xml are optional, frequently-used Solr configuration files that you post using this URL.