Switch Solr indexes

Abstract

Describes how to switch Solr indexes after rebuilding.

You can set up Solr to rebuild an index in a separate core so that the rebuilding does not affect the search index that is currently used. Once the rebuilding and the optimization of the index completes, Sitecore switches the two cores, and the rebuilt and optimized index is used.

The SwitchOnRebuildSolrSearchIndex class inherits from the SolrSearchIndex class and adds the capability of maintaining two cores for a particular index. Because this is only important for production environments, you can reconfigure your custom index with the SwitchOnRebuildSolrSearchIndex implementation during testing and before moving to a production environment.

When it has fully rebuild the index, Sitecore switches the primary and secondary cores by sending a SWAP request to Solr.

To create a duplicate Solr index and set up Solr to rebuild an index in a separate core:

  1. From the Solr server, copy the existing itembuckets folder. Call the copy itembuckets_sec.

  2. Update the itembuckets_sec/core.properties file and set name of the new core:

    name=itembuckets_sec

  3. Restart Solr.

  4. Check the two cores. You can do this by visiting these URLs (change as appropriate for your actual setup):

    http://localhost:8983/solr/itembuckets/select/?q=*:*&version=2.2&start=0&rows=10&indent=on

    http://localhost:8983/solr/itembuckets_sec/select/?q=*:*&version=2.2&start=0&rows=10&indent=on

    Both should return 0 results (but you will see some XML).

  5. To use this implementation, change the type reference on a particular search index to Sitecore.ContentSearch.SolrProvider.SwitchOnRebuildSolrSearchIndex, and add the rebuildcore parameter:

    <indexes hint="list:AddIndex">
   <index id="content_index"
          type="Sitecore.ContentSearch.SolrProvider.SwitchOnRebuildSolrSearchIndex, 
                Sitecore.ContentSearch.SolrProvider">
       <param desc="name">$(id)</param>
        <param desc="core">itembuckets</param>
  <param desc="rebuildcore">itembuckets_sec</param>
...

Note

After you have changed the configuration file, your website uses indexes from the primary core. Each time you initiate a full index rebuild, Sitecore does this in the secondary core. The secondary core then becomes the primary one after the rebuild.

Separate cores for each index

If you configure multiple indexes to share the same core, then the secondary core becomes the primary for all indexes each time you perform a full index rebuild.

For example, assume that you have a configuration similar to this:

<index id="sitecore_web_index" type="Sitecore.ContentSearch.SolrProvider.SwitchOnRebuildSolrSearchIndex, Sitecore.ContentSearch.SolrProvider">
    <param desc="name">$(id)</param>
    <param desc="core">itembucket</param>
    <param desc="rebuildcore">itembucket_web_rebuild</param>
...
<index id="sitecore_master_index" type="Sitecore.ContentSearch.SolrProvider.SolrSearchIndex, Sitecore.ContentSearch.SolrProvider">
    <param desc="name">$(id)</param>
    <param desc="core">itembucket</param>
    <param desc="propertyStore" ref="contentSearch/databasePropertyStore" param1="$(id)" />
...

When Sitecore has finished rebuilding the index, both indexes use the itembucket_web_rebuild core, even if you have not specified the SwitchOnRebuild behavior for the sitecore_master_index index.

For this reason, you should configure separate cores for each index in production. You can do this by using configuration similar to this:

<index id="sitecore_web_index" type="Sitecore.ContentSearch.SolrProvider.SwitchOnRebuildSolrSearchIndex, Sitecore.ContentSearch.SolrProvider">
    <param desc="name">$(id)</param>
    <param desc="core">$(id)</param>
    <param desc="rebuildcore">$(id)_rebuild</param>
...
<index id="sitecore_master_index" type="Sitecore.ContentSearch.SolrProvider.SolrSearchIndex, Sitecore.ContentSearch.SolrProvider">
    <param desc="name">$(id)</param>
    <param desc="core">$(id)</param>
    <param desc="propertyStore" ref="contentSearch/databasePropertyStore" param1="$(id)" />
...

This helps you avoid unclear behaviors involving SwitchOnRebuild and cache clearing.