Platform Administration and Architecture

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.

Note

In Sitecore 9, Update 2, and later there is also support for switching SolrCloud indexes.

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.

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.

Note

The features described in this section are available in Sitecore 9, Update 2, and later.

You use the SwitchOnRebuildSolrSearchIndex class to rebuild and switch Solr indexes. This implementation uses the Solr SWAP command to swap the active and the rebuild indexes.

The mechanism for maintaining and switching two indexes is different when use SolrCloud. The implementation in the SwitchOnRebuildSolrCloudSearchIndex class uses collection aliases: it uses the active alias for search and update operations and the rebuild alias for rebuild operations. When a rebuild operation finishes, the CREATEALIAS command swaps the collections the aliases reference.

The configuration is similar to what is described for Solr, except for this:

<index id="sitecore_web_index" type="Sitecore.ContentSearch.SolrProvider.SwitchOnRebuildSolrCloudSearchIndex, Sitecore.ContentSearch.SolrProvider">
  <param desc="mainalias">$(id)MainAlias</param>
  <param desc="rebuildalias">$(id)RebuildAlias</param>
  <param desc="collection">$(id)</param>
  <param desc="rebuildcollection">$(id)_rebuild</param>
...
</index>

where

  • mainalias and rebuildalias: names for active and rebuild aliases respectively which will be used by a Sitecore index.

  • collection and rebuildcollection: names of Solr collections which will be used for storing the Sitecore index.

If the ContentSearch.Solr.EnforceAliasCreation setting is true, a Sitecore instance creates aliases and maps them to collections if they do not already exist. You can also create the aliases manually.