Today, I am going to explain the process of creating and maintaining the Solr cores within a Sitecore environment using the SwitchOnRebuild indexing strategy. This strategy is designed to avoid downtime during the index rebuilding processes by utilizing a dual-core mechanism that allows the search functionality to stay fully operational and deliver consistently along with seamless responses to the users even when the indexes are being rebuilt in the background.
Maintaining the search performance and accuracy is of prime importance while you are working with Sitecore at scale i.e., in a production environment. One such operation is rebuilding the Solr indexes, particularly on content changes or after deployments. However, rebuilding indexes directly in a live environment will result in downtime or performance impacts, especially for the components that are related to Solr. That is where Sitecore's "switchOnRebuild" Solr indexes play their role by enabling a zero-downtime index switching possible.
What is the SwitchOnRebuild Index?
A switchOnRebuild indexing is a special kind of Solr indexing strategy defined in your Sitecore configuration. Rather than referencing a single core, it encloses two Solr cores: an active core and a rebuild core.
During a rebuilding index process,
1. Sitecore reconstructs or reindexes the content into the rebuild core.
2. Once complete, it switches the reference of the active core to the newly rebuilt core.
3. That implies users and Sitecore services never have to experience downtime or inconsistency thus queries are always striking a completely built, live core.
How It Works
SwitchOnRebuildSolrSearchIndex Pattern in Sitecore
Sitecore's SwitchOnRebuildSolrSearchIndex pattern is designed to ensure search on website availability even during the index rebuild operations by maintaining two Solr cores for each logical index:
A. <indexname> - It is the currently active core used by Sitecore for Solr queries and responses.
B. <indexname>_rebuild - It is the staging core used during index rebuilds.
Rebuild Process
When a rebuild is triggered, Sitecore performs the following steps:
1. Rebuilds the index into the <indexname>_rebuild core.
2. Once the rebuild is successfully completed the Sitecore swaps the core references so that the <indexname>_rebuild becomes the new active core.
3. The previous active core is now available for future rebuilds.
This mechanism ensures zero downtime during indexing operations and allows for a safe rollback if needed.
Configuration Example
<?xml version="1.0" encoding="UTF-8"?>
<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/">
<sitecore>
<contentSearch>
<configuration type="Sitecore.ContentSearch.ContentSearchConfiguration, Sitecore.ContentSearch">
<indexes hint="list:AddIndex">
<index id="sitecore_master_index" type="Sitecore.ContentSearch.SolrProvider.SwitchOnRebuildSolrSearchIndex, Sitecore.ContentSearch.SolrProvider">
<!-- Logical name of the index -->
<param desc="name">sitecore_master_index</param>
<!-- Optional: specify the core name for rebuild, defaults to <name>_rebuild -->
<param desc="rebuildcore">sitecore_master_index_rebuild</param>
<!-- Reference the Solr core this index will write to and query -->
<param desc="core">sitecore_master_index</param>
<!-- Reference the configuration rules to use for indexing -->
<configuration ref="contentSearch/indexConfigurations/defaultSolrIndexConfiguration">
<enableReadAccessIndexing>true</enableReadAccessIndexing>
</configuration>
<!-- This node tells Sitecore which databases to index -->
<locations hint="list:AddCrawler">
<crawler type="Sitecore.ContentSearch.SitecoreItemCrawler, Sitecore.ContentSearch">
<database>master</database>
<root>/sitecore/content</root>
</crawler>
</locations>
</index>
</indexes>
</configuration>
</contentSearch>
</sitecore>
</configuration>Configuring SwitchOnRebuild Indexes
To enable the SwitchOnRebuild indexing strategy in your Sitecore with Solr setup, make sure the following steps are completed:
1. Enable SwitchOnRebuild in your index definitions
In your App_Config patch files (e.g., z.Sitecore.ContentSearch.Solr.DefaultIndexConfiguration.config or a custom patch file), define each index using:
type="Sitecore.ContentSearch.SolrProvider.SwitchOnRebuildSolrSearchIndex, Sitecore.ContentSearch.SolrProvider"
2. Create dual Solr cores for each index
Each logical index must have:
A main Solr core (e.g., sitecore_web_index)
A rebuild core (e.g., sitecore_web_index_rebuild)
These can be created by duplicating an existing core’s folder and updating core.properties.
3. Ensure Solr knows about both cores
If using standalone Solr then Confirm both cores are defined in solr.xml and visible in the Solr admin UI.
If using SolrCloud then Create both collections with consistent configuration (schema, configsets, etc.).
Triggering a Rebuild
You can trigger an index rebuild via:
1. The Sitecore Control Panel → Indexing → Indexing Manager
2. Programmatically via the code below.
using Sitecore.ContentSearch;
using Sitecore.ContentSearch.Maintenance;
var index = ContentSearchManager.GetIndex("sitecore_web_index");
IndexCustodian.RebuildIndex(index, true);Sitecore will handle the core switch internally when using SwitchOnRebuildSolrSearchIndex.
Benefits
Zero Downtime Indexing - Indexing operations are performed quietly and seamlessly in the background while ensuring that the currently active Solr core continues to serve the live traffic without any interruptions. This allows users to search and retrieve content in real-time while the new index is being built in the background.
No Performance Impact During Rebuild - The indexing process will not interfere with the performance of the live site. Since the rebuild happens on a separate core hence it eliminates any degradation in response times or resource contention issues during high-traffic periods.
Data Consistency Guaranteed - Users and integrated services will always be going to access a fully indexed and consistent dataset. Sitecore ensures that content is only switched to the new core after the rebuild completes successfully which will avoid any partial or inconsistent data exposure.
Safe Rollback Mechanism - In the case of a failure during the index rebuild process, Sitecore will continue to utilize the previously active core without any disruption. This built-in safety prevents any downtime or negative user experience due to failed indexing attempts.
Best Practices
Monitor Index Rebuild Times - It is important to regularly monitor and analyze the time it takes to rebuild indexes, especially in environments with large or frequently updated content repositories. Understanding these metrics helps in planning and optimizing rebuild schedules to avoid performance bottlenecks.
Integrate Index Rebuilds into Deployment Pipelines - Automate the index rebuild process as part of your deployment workflows. By triggering the rebuilds immediately after code or content deployments, you can ensure that search results always reflect the most current state of the content.
Maintain Consistent Core Naming Conventions - It is advised to follow Sitecore’s expected naming pattern for Solr cores, particularly by appending the _rebuild suffix to secondary cores. Consistency in naming not only ensures compatibility but also simplifies core management and reduces configuration errors.
References
Switch Solr indexes - https://doc.sitecore.com/xp/en/developers/latest/platform-administration-and-architecture/switch-solr-indexes.html
Sitecore SwitchOnRebuild with Managed Search - https://www.searchstax.com/docs/sitecore-switchonrebuild