Setting up the Sitecore SwitchOnRebuild feature with the SearchStax SolrCloud is as simple as following the path through the woods to Grandma’s house. What could possibly go wrong?
Sitecore applications and websites frequently have massive content with high turnover. Site search becomes a challenge in these situations because the most-efficient way to update these indexes is to rebuild them. However, rebuilding a large index can take hours which means that the search service would be unavailable. For the majority of sites, any downtime is unacceptable.
Enter Sitecore Switch SolrCloud indexes, also referred to as the SwitchOnRebuild class. This feature, available since Sitecore 9 Update 2 (v 9.0-2), lets Sitecore rebuild its index as a new Solr core while ensuring high availability by serving queries from the previous index during the rebuild. Once the rebuild is finished, Sitecore automatically switches over from the old core to the new one and the old core is then deleted.
SwitchOnRebuild is an elegant solution to a difficult problem, but it is not always easy to set up and there are a couple of red flags to watch for.
Red Flag #1 – Moving from Standalone to SolrCloud
Before we get started, let’s wave a red flag at one common scenario. Many Sitecore users begin with a Proof-of-Concept (POC) project where they hook up Sitecore to a local standalone Solr deployment for testing. SwitchOnRebuild is easy to set up and works well in this use case. However, when the deployment is scaled up to SolrCloud things can go inexplicably wrong. In extreme cases, the Solr index can become damaged and unusable.
SwitchOnRebuild works for both stand-alone and SolrCloud implementations, but not in the same way. We have a brief writeup on this topic in our FAQs: Can we use Sitecore’s SwitchOnRebuild with SearchStax? If you use SwitchOnRebuild with SearchStax, you have to take a different path through the forest and make sure you use the SolrCloud version.
Red Flag #2 – The Big Bad Wolf in the Forest
Another red flag involves the Sitecore Index Manager. You have set up Sitecore to use a SolrCloud deployment, but when you try to refresh the index from the Sitecore Index Manager, the system seems to hang. In many cases, it takes up to 15 minutes for the Rebuild Index dialog box to appear. In the meantime, most people don’t have the patience to wait for the dialog box and assume that the configuration has failed. They find “Unable to connect to the remote server” exceptions in the log files which is a very discouraging and misunderstood message that leads to wrong conclusions about what happened.
This has been a known issue since Sitecore 9.0-2. Oddly, if you are patient and just wait for the system to catch up, the resulting configuration will be fine. The other work-around is to refresh the indexes using the Content Editor instead of the Index Manager. (In this case, this Big Bad Wolf turns out to be more of a Cowardly Lion.)
With the red flags out of the way, how do you set up Sitecore and SolrCloud to use SwitchOnRebuild?
The Magic Spell for Setting Up Sitecore Using SearchStax
For readers setting up Sitecore SolrCloud using SearchStax, we have Documentation pages on installing and integrating a stand-alone Sitecore with a cloud-based Solr deployment and every version of Sitecore handles things it a little differently.
Note that SearchStax provides a PowerShell plugin that sets up all of the Sitecore and Solr configurations automatically in less than a minute. Learn more about the Sitecore Solr Plugin from SearchStax. The Sitecore Solr plugin is a magic spell that teleports you to your destination in a hurry.
Step 1 – Enable SolrCloud Mode in Sitecore
Perform the manual Sitecore/Solr setup, or run the SearchStax Sitecore Plugin. Then make these modifications to enable SwitchOnRebuild.
- Go to <root>\App_Config\ConnectionStrings.config, and update the solr.search tag to have ;solrCloud=true at the end.
<add name="solr.search" connectionString="https://ssXXXXXX-o6zpwllq-us-west-1-aws.searchstax.com/solr;solrCloud=true" />
- Restart IIS and refresh Sitecore.
Step 2 – Update Sitecore to use SwitchOnRebuild
This procedure might be different if you have configured some custom config files.
- For default setup, navigate to <root>\App_Config\Include\Examples\Sitecore.ContentSearch.SolrCloud.SwitchOnRebuild.config.example and move the file and change the file name to <root>\App_Config\Sitecore\ContentSearch\Sitecore.ContentSearch.SolrCloud.SwitchOnRebuild.config.
- Restart Sitecore.
Step 3 – Update Solr
- As per the default config file, you will have to create appropriate collections and aliases before Sitecore can use the SwitchOnRebuild functionality.
- Navigate to the above file, and there will be a section as follows:
<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>
- The above section translates to following:
- “$(id)”: A collection named “sitecore_web_index”
- “$(id)_rebuild”: A collection named “sitecore_web_index_rebuild”
- “$(id)MainAlias”: An alias named “sitecore_web_indexMainAlias” pointing to “sitecore_web_index”.
- “$(id)RebuildAlias”: An alias named “sitecore_web_indexRebuildAlias” pointing to “sitecore_web_index_rebuild”.
- You need to create the above-mentioned collections and aliases with exactly the same name as they appear in this file.
- By default Sitecore enables the SwitchOnRebuild for sitecore_master_index, sitecore_web_index, and sitecore_core_index. If you want to alter that, then make the changes in the file mentioned in Step 2.
- Now you can trigger an index rebuild in Sitecore and verify.
SearchStax and Sitecore
SwitchOnRebuild is a very important Sitecore feature and many websites could not function without it. Unfortunately, it is easy to get lost in the woods as the setup can be complicated, there are multiple pitfalls to avoid and the visible error messages are sometimes not very useful.