How to Add Custom Solr Indexes in SolrCloud
For those running SolrCloud in a windows server environment, it’s a common requirement to add custom Solr indexes to support your Sitecore environment. Whether you have blogs, products, or any other set of custom data you want to support Solr side, the following details how to setup custom Solr indexes within your Sitecore environment. In this article, we will use the example of a blog index.
IMPORTANT: Any scripts or configuration files are for example use only. Use at your own risk.
Contents
SolrCloud Assumptions
For the purposes of our custom blog index, we have the following assumptions:
- SwitchOnRebuild will be enabled along with EnforceAliases
- The nomenclature for our custom index will be sitecore_blog_master_index or sitecore_blog_web_index
- SolrCloud is running on a Windows VM. Note that SolrCloud can run as a single node. SolrCloud is a technology not a declaration of scale for regular Solr. A typical setup for scaled SolrCloud is 3 nodes with 3 Zookeepers. Per Apache Solr, they offer the following guidance:
To properly maintain a quorum, it’s highly recommended to have an odd number of ZooKeeper servers in your ensemble, so a majority is maintained.
To explain why, think about this scenario: If you have two ZooKeeper nodes and one goes down, this means only 50% of available servers are available. Since this is not a majority, ZooKeeper will no longer serve requests.
However, if you have three ZooKeeper nodes and one goes down, you have 66% of your servers available and ZooKeeper will continue normally while you repair the one down node. If you have 5 nodes, you could continue operating with two down nodes if necessary.
It’s not generally recommended to go above 5 nodes. While it may seem that more nodes provide greater fault-tolerance and availability, in practice it becomes less efficient because of the amount of inter-node coordination that occurs. Unless you have a truly massive Solr cluster (on the scale of 1,000s of nodes), try to stay to 3 as a general rule, or maybe 5 if you have a larger cluster.
ZooKeeper Ensemble Configuration :: Apache Solr Reference Guide
Enable SwitchOnRebuild and EnforceAliases
Our first step is to ensure we are using SwitchOnRebuild for the default Sitecore indexes as we want to be consistent with our custom indexes (and more importantly, you don’t want pages down while waiting for SolrCloud to rebuild an active index… so always use SwitchOnRebuild).
To achieve this, you can copy the Sitecore.ContentSearch.SolrCloud.SwitchOnRebuild.config.example file from the Include Examples directory (wwwroot\App_Config\Include\Examples) and remove the .example from the file name and place it in a zzz directory.
Important! There is a SwitchOnRebuild for Solr in the same directory but we want SolrCloud. Read more about SwitchOnRebuild at: Switch Solr indexes | Sitecore Documentation
I also prefer to enforce alias creation, so I don’t need to create the SolrCloud aliases manually. These aliases are critical to the SwitchOnRebuild process as Sitecore will point to an alias such as “indexName”MainAlias and the index name after the colon is the index that is active (not being rebuilt). This index gets swapped into the “indexName”MainAlias once it is rebuilt.
In the screenshot below if we look at sitecore_web_indexMainAlias, the index being used could be sitecore_web_index or sitecore_web_index_rebuild depending which index is being rebuilt. Once rebuilt, they swap. If I ran a Solr indexing operation on this index from the Sitecore CMS, the sitecore_web_indexMainAlias would point/have sitecore_web_index_rebuild after the colon once the rebuild is complete.

Below are the contents of the Sitecore.ContentSearch.SolrCloud.SwitchOnRebuild.config.example file for a Sitecore 10 environment, except I set EnforceAliases to “true”.
Note the highlighted areas in how the patch declares the aliases and rebuild collection names based on the index name as a parameter… and where I set enforce aliases to true (the default is false).
IMPORTANT: The order matters for the attributes (ex. MainAlias, RebuildAlias, RebuildCollection) as noted in this article: Sitecore Quicktip: Could not find configuration node may be a Solr issue
<?xml version="1.0" encoding="utf-8" ?>
<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/" xmlns:role="http://www.sitecore.net/xmlconfig/role/" xmlns:search="http://www.sitecore.net/xmlconfig/search/">
<sitecore role:require="Standalone or ContentManagement" search:require="Solr">
<contentSearch>
<configuration type="Sitecore.ContentSearch.ContentSearchConfiguration, Sitecore.ContentSearch">
<indexes hint="list:AddIndex">
<!-- MASTER INDEX configuration -->
<!-- Replaces the default SolrSearchIndex type which uses aliases with a swap command that allows Sitecore to start up even when a Solr connection is not available.
Once the Solr connection comes back, the patch restarts the application and initializes the Solr index.
A SwitchOnRebuild index expects 4 parameters to be passed to the constructor:
mainalias: The alias name for the primary index operations.
The ContentSearch.Solr.EnforceAliasCreation setting controls whether the alias should be created automatically.
It must have only one collection assigned to it.
rebuildalias: The alias name for the rebuild index operations.
The ContentSearch.Solr.EnforceAliasCreation setting controls whether the alias should be created automatically.
It must have only one collection assigned to it.
collection: The primary index collection name.
rebuildcollection: The rebuild index collection name.
-->
<index id="sitecore_master_index">
<patch:attribute name="type" value="Sitecore.ContentSearch.SolrProvider.SwitchOnRebuildSolrCloudSearchIndex, Sitecore.ContentSearch.SolrProvider" />
<param desc="core">
<patch:delete />
</param>
<param desc="rebuildcore">
<patch:delete />
</param>
<param patch:after="*[@desc='name']" desc="mainalias">$(id)MainAlias</param>
<param patch:after="*[@desc='mainalias']" desc="rebuildalias">$(id)RebuildAlias</param>
<param patch:after="*[@desc='rebuildalias']" desc="collection">$(id)</param>
<param patch:after="*[@desc='collection']" desc="rebuildcollection">$(id)_rebuild</param>
</index>
<!-- WEB INDEX configuration -->
<!-- Replaces the default SolrSearchIndex type which uses aliases with a swap command that allows Sitecore to start up even when a Solr connection is not available.
Once the Solr connection comes back, the patch restarts the application and initializes the Solr index.
A SwitchOnRebuild index expects 4 parameters to be passed to the constructor:
mainalias: The alias name for the primary index operations.
The ContentSearch.Solr.EnforceAliasCreation setting controls whether the alias should be created automatically.
It must have only one collection assigned to it.
rebuildalias: The alias name for the rebuild index operations.
The ContentSearch.Solr.EnforceAliasCreation setting controls whether the alias should be created automatically.
It must have only one collection assigned to it.
collection: The primary index collection name.
rebuildcollection: The rebuild index collection name.
-->
<index id="sitecore_web_index">
<patch:attribute name="type" value="Sitecore.ContentSearch.SolrProvider.SwitchOnRebuildSolrCloudSearchIndex, Sitecore.ContentSearch.SolrProvider" />
<param desc="core">
<patch:delete />
</param>
<param desc="rebuildcore">
<patch:delete />
</param>
<param patch:after="*[@desc='name']" desc="mainalias">$(id)MainAlias</param>
<param patch:after="*[@desc='mainalias']" desc="rebuildalias">$(id)RebuildAlias</param>
<param patch:after="*[@desc='rebuildalias']" desc="collection">$(id)</param>
<param patch:after="*[@desc='collection']" desc="rebuildcollection">$(id)_rebuild</param>
</index>
<!-- CORE INDEX configuration -->
<!-- Replaces the default SolrSearchIndex type which uses aliases with a swap command that allows Sitecore to start up even when a Solr connection is not available.
Once the Solr connection comes back, the patch restarts the application and initializes the Solr index.
A SwitchOnRebuild index expects 4 parameters to be passed to the constructor:
mainalias: The alias name for the primary index operations.
The ContentSearch.Solr.EnforceAliasCreation setting controls whether the alias should be created automatically.
It must have only one collection assigned to it.
rebuildalias: The alias name for the rebuild index operations.
The ContentSearch.Solr.EnforceAliasCreation setting controls whether the alias should be created automatically.
It must have only one collection assigned to it.
collection: The primary index collection name.
rebuildcollection: The rebuild index collection name.
-->
<index id="sitecore_core_index">
<patch:attribute name="type" value="Sitecore.ContentSearch.SolrProvider.SwitchOnRebuildSolrCloudSearchIndex, Sitecore.ContentSearch.SolrProvider" />
<param desc="core">
<patch:delete />
</param>
<param desc="rebuildcore">
<patch:delete />
</param>
<param patch:after="*[@desc='name']" desc="mainalias">$(id)MainAlias</param>
<param patch:after="*[@desc='mainalias']" desc="rebuildalias">$(id)RebuildAlias</param>
<param patch:after="*[@desc='rebuildalias']" desc="collection">$(id)</param>
<param patch:after="*[@desc='collection']" desc="rebuildcollection">$(id)_rebuild</param>
</index>
</indexes>
</configuration>
</contentSearch>
<settings>
<!-- ENFORCES ALIAS CREATION ON INDEX INITIALIZATION
If enabled, index aliases will be created on Solr during the index initialization process.
Default vaue: false
-->
<setting name="ContentSearch.Solr.EnforceAliasCreation" value="true" />
</settings>
</sitecore>
</configuration>
Creating Indexes Using PowerShell
With the aforementioned in place, you will have your default Sitecore indexes using SwitchOnRebuild. Now we need to build out our custom Solr indexes.
Create ConfigSets
To achieve this, I prefer to run PowerShell on one of the SolrCloud nodes. The first step is to create the ConfigSet as it holds the schema we will use. One of the main benefits of a separate index is being able to declare a differing schema than the default Sitecore schema.
<#
Author: Kelly Rusk
Description: Create ConfigSets in SolrCloud
#>
param (
[string]$solrPrefix = 'sitecore', # Prefix to give collection
[string]$solrVersion = '8.8.2',
[String]$solrInstallDrive = 'S', # Drive Where Solr is installed
[String]$zooKeeperPort = '9984' # 9984 for Single Node SolrCloud and 2181 for Scaled SolrCloud Nodes (ex. 3 Nodes)
)
# Collections and the ConfigSets They Belong to Array (You can bulk create by adding more $configSets += variables)
$configSets = @()
$configSets += "sitecore_blog"
$zkHosts = @() # Add Multiple Entries if 3 Nodes
$zkHosts += 'zks1.myzookeepernode.com'
# Set TLS for Script Execution
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
# Check ConfigSet(s)
foreach ($configSet in $configSets) {
Write-Output "ConfigSet named $configSet will be created and added to Zookeeper"
}
# Set Zookeeper Hosts
$zkHostsWithPort = @($($zkHosts))
for ($i = 0; $i -lt $zkHostsWithPort.Count; $i++) {
$zkHostsWithPort[$i] = $zkHostsWithPort[$i] + ":$($zooKeeperPort)"
}
$zkHostsWithPort = $zkHostsWithPort -join ','
# Check Zookeeper
Write-Output "ConfigSets will use the Zookeeper host(s) $zkHostsWithPort"
# Create ConfigSet(s) and Upload to Zookeeper
foreach ($configSet in $configSets) {
# Create Configset
Copy-Item -Path "${solrInstallDrive}:\solr-$solrVersion\server\solr\configsets\_default" -Destination "${solrInstallDrive}:\solr-$solrVersion\server\solr\configsets\$($configSet)_configs" -Recurse
if (Test-Path -Path "${solrInstallDrive}:\solr-$solrVersion\server\solr\configsets\$($configSet)_configs\conf\solrconfig.xml") {
$newCfg = Get-Content "${solrInstallDrive}:\solr-$solrVersion\server\solr\configsets\$($configSet)_configs\conf\solrconfig.xml"
Rename-Item "${solrInstallDrive}:\solr-$solrVersion\server\solr\configsets\$($configSet)_configs\conf\solrconfig.xml" "${solrInstallDrive}:\solr-$solrVersion\server\solr\configsets\$($configSet)_configs\conf\solrconfig.xml.old"
$newCfg = $newCfg | ForEach-Object { $_ -replace "update.autoCreateFields:true", "update.autoCreateFields:false" }
$newCfg | Set-Content "${solrInstallDrive}:\solr-$solrVersion\server\solr\configsets\$($configSet)_configs\conf\solrconfig.xml" -Encoding UTF8
}
# Change ID to UniqueID
if (!(Test-Path -Path "${solrInstallDrive}:\solr-$solrVersion\server\solr\configsets\$($configSet)_configs\conf\managed-schema.old")) {
$newCfg = Get-Content "${solrInstallDrive}:\solr-$solrVersion\server\solr\configsets\$($configSet)_configs\conf\managed-schema"
Rename-Item "${solrInstallDrive}:\solr-$solrVersion\server\solr\configsets\$($configSet)_configs\conf\managed-schema" "${solrInstallDrive}:\solr-$solrVersion\server\solr\configsets\$($configSet)_configs\conf\managed-schema.old"
$newCfg = $newCfg | ForEach-Object { $_ -replace "<uniqueKey>id</uniqueKey>", "<uniqueKey>_uniqueid</uniqueKey>" }
$newCfg | Set-Content "${solrInstallDrive}:\solr-$solrVersion\server\solr\configsets\$($configSet)_configs\conf\managed-schema" -Encoding UTF8
}
# Add Field Type for Unique ID
$Match = [regex]::Escape('<field name="_text_" type="text_general" indexed="true" stored="false" multiValued="true"/>')
$NewLine = '<field name="_uniqueid" type="string" indexed="true" required="true" stored="true"/>'
$Content = Get-Content "${solrInstallDrive}:\solr-$solrVersion\server\solr\configsets\$($configSet)_configs\conf\managed-schema"
$Index = ($content | Select-String -Pattern $Match).LineNumber + 1
$NewContent = @()
0..($Content.Count - 1) | Foreach-Object {
if ($_ -eq $index) {
$NewContent += $NewLine
}
$NewContent += $Content[$_]
}
$NewContent | Out-File "${solrInstallDrive}:\solr-$solrVersion\server\solr\configsets\$($configSet)_configs\conf\managed-schema" -Encoding utf8
# Upload configset
$pinfo = New-Object System.Diagnostics.ProcessStartInfo
$pinfo.FileName = "${solrInstallDrive}:\solr-$solrVersion\bin\solr.cmd"
Write-Output $pinfo.FileName
$pinfo.RedirectStandardError = $true
$pinfo.RedirectStandardOutput = $true
$pinfo.UseShellExecute = $false
$pinfo.Arguments = "zk upconfig -d $($configSet)_configs -n $configSet -z $($zkHostsWithPort.split(',')[0])"
Write-Output $pinfo.Arguments
$p = New-Object System.Diagnostics.Process
$p.StartInfo = $pinfo
$p.Start() | Out-Null
$stdout = $p.StandardOutput.ReadToEnd()
$stderr = $p.StandardError.ReadToEnd()
$p.WaitForExit()
Write-Output $stdout
Write-Output $stderr
}
Create Collections
With the ConfigSet for our custom blog indexes created, we will now create the collections/indexes that use the ConfigSet. Again, running PowerShell on one of the nodes, we will not only declare the indexes we want to create but also the shards and replication factor. Assuming a 3-node SolrCloud environment, I tend to keep a replica count of 2 and only 1 shard as I have found sharding to be fragile at times.
Note that the indexes created are for both the master and web Blog indexes inclusive of their rebuild indexes. This is critical for when we come to the step of creating our Sitecore configurations that utilize these SolrCloud indexes.
<#
Author: Kelly Rusk
Description: Create collections in SolrCloud
#>
param (
[string]$solrPrefix = 'sitecore', #prefix to give collection
[string]$solrCloudNode = 'zks1.mysolrnode.com', # Node to connect into using the api to create collections
[int]$shardCount = 1, # Shard count to use (Keep at 1 shard. Sharding is problematic at best)
[int]$replFact = 2 # Replication factor to use (Use 1 for Single Node SolrCloud, and 2 for Scaled (3) Node SolrCloud)
)
# Collections and the ConfigSets They Belong to Array
$cores = @(
[pscustomobject]@{core = "$solrPrefix" + "_blog_master_index"; configset = 'sitecore_blog' }
[pscustomobject]@{core = "$solrPrefix" + "_blog_master_index_rebuild"; configset = 'sitecore_blog' }
[pscustomobject]@{core = "$solrPrefix" + "_blog_web_index"; configset = 'sitecore_blog' }
[pscustomobject]@{core = "$solrPrefix" + "_blog_web_index_rebuild"; configset = 'sitecore_blog' }
)
# Set TLS for Script Execution
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
# Check Collections and ConfigSets
foreach ($core in $cores) {
Write-Output "Collection named $($core.core) will be created and added to the configSet named $($core.configset)"
}
# Check Collections and Add to the Proper ConfigSets
foreach ($core in $cores) {
$uri = "https://$($solrCloudNode):8984/solr/admin/collections?action=CREATE&name=$($core.core)&numShards=$shardCount&replicationFactor=$replFact&collection.configName=$($core.configset)"
Write-Output "Adding $($core.core) to $solrCloudNode with a shard count of $shardCount, a replication factor of $replFact and using config name $($core.configset)"
$response = Invoke-RestMethod -Method post -Uri $uri
Write-Output "Response from SolrCloud: $($response)"
}
Sitecore SolrCloud Configurations
Finally, we are ready to create our Sitecore SolrCloud Configurations for our blog indexes with SwitchOnRebuild. A few important notes:
- We need a Master Index configuration and Web Index configuration to be placed on the Content Management node
- We need a smaller Web Index configuration to be placed on the Content Delivery nodes
- In my examples, I am setting the environment:require to target non-local environments, as a local developer may not have SwitchOnRebuild enabled (but should consider it). To target a local environment, you would set
environment:require="Local"
CMS Based Master Index with SwitchOnRebuild
This targeted configuration file for non-local environments should be deployed to your CMS, preferably in a folder within the App_Config>Includes directory using a name such as “SolrCloudConfigs” to help organize your include files. This is for rebuilding the Blog master index for items in the CMS.
<?xml version="1.0" encoding="utf-8" ?>
<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/" xmlns:role="http://www.sitecore.net/xmlconfig/role/" xmlns:search="http://www.sitecore.net/xmlconfig/search/" xmlns:environment="http://www.sitecore.net/xmlconfig/environment/">
<sitecore role:require="Standalone or ContentManagement" search:require="solr" environment:require="!Local">
<contentSearch>
<configuration type="Sitecore.ContentSearch.ContentSearchConfiguration, Sitecore.ContentSearch">
<indexes hint="list:AddIndex">
<index id="sitecore_blog_master_index" type="Sitecore.ContentSearch.SolrProvider.SwitchOnRebuildSolrCloudSearchIndex, Sitecore.ContentSearch.SolrProvider">
<param desc="name">$(id)</param>
<param desc="mainalias">$(id)MainAlias</param>
<param desc="rebuildalias">$(id)RebuildAlias</param>
<param desc="collection">$(id)</param>
<param desc="rebuildcollection">$(id)_rebuild</param>
<param desc="propertyStore" ref="contentSearch/indexConfigurations/databasePropertyStore" param1="$(id)" />
<configuration ref="contentSearch/indexConfigurations/BlogSolrIndexConfiguration">
<enableReadAccessIndexing>true</enableReadAccessIndexing>
</configuration>
<strategies hint="list:AddStrategy">
<strategy ref="contentSearch/indexConfigurations/indexUpdateStrategies/intervalAsyncMaster" role:require="Standalone or (ContentManagement and Indexing)" />
</strategies>
<locations hint="list:AddCrawler">
<crawler type="Sitecore.ContentSearch.SitecoreItemCrawler, Sitecore.ContentSearch">
<Database>master</Database>
<Root>/sitecore</Root>
</crawler>
</locations>
<enableItemLanguageFallback>false</enableItemLanguageFallback>
<enableFieldLanguageFallback>false</enableFieldLanguageFallback>
</index>
</indexes>
</configuration>
</contentSearch>
</sitecore>
</configuration>
CMS Based Web Index with SwitchOnRebuild
This targeted configuration file for non-local environments should be deployed to your CMS, preferably in a folder within the App_Config>Includes directory using a name such as “SolrCloudConfigs” to help organize your include files. This is for rebuilding the Blog web index that users interact with on the CDs.
Important! Web indexes require two separate configuration files… one for the CMS with SwitchOnRebuild to rebuild the index users will retrieve data from… and a second for the CDs for reading the SolrCloud Web index from the CD Server that does not require SwitchOnRebuild as it will read from the MainAlias to get and display SolrCloud index data.
<?xml version="1.0" encoding="utf-8" ?>
<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/" xmlns:role="http://www.sitecore.net/xmlconfig/role/" xmlns:search="http://www.sitecore.net/xmlconfig/search/" xmlns:environment="http://www.sitecore.net/xmlconfig/environment/">
<sitecore role:require="ContentManagement" search:require="solr" environment:require="!Local">
<contentSearch>
<configuration type="Sitecore.ContentSearch.ContentSearchConfiguration, Sitecore.ContentSearch">
<indexes hint="list:AddIndex">
<index id="sitecore_blog_web_index" type="Sitecore.ContentSearch.SolrProvider.SwitchOnRebuildSolrCloudSearchIndex, Sitecore.ContentSearch.SolrProvider">
<param desc="name">$(id)</param>
<param desc="mainalias">$(id)MainAlias</param>
<param desc="rebuildalias">$(id)RebuildAlias</param>
<param desc="collection">$(id)</param>
<param desc="rebuildcollection">$(id)_rebuild</param>
<param desc="propertyStore" ref="contentSearch/indexConfigurations/databasePropertyStore" param1="$(id)" />
<configuration ref="contentSearch/indexConfigurations/BlogSolrIndexConfiguration" />
<strategies hint="list:AddStrategy">
<strategy ref="contentSearch/indexConfigurations/indexUpdateStrategies/onPublishEndAsyncSingleInstance" role:require="Standalone or (ContentManagement and Indexing) or (ContentDelivery and Indexing)" />
</strategies>
<locations hint="list:AddCrawler">
<crawler type="Sitecore.ContentSearch.SitecoreItemCrawler, Sitecore.ContentSearch">
<Database>web</Database>
<Root>/sitecore</Root>
</crawler>
</locations>
<enableItemLanguageFallback>false</enableItemLanguageFallback>
<enableFieldLanguageFallback>false</enableFieldLanguageFallback>
</index>
</indexes>
</configuration>
</contentSearch>
</sitecore>
</configuration>
CDS Based Web Index without SwitchOnRebuild
This targeted configuration file for non-local environments should be deployed to your CDS, preferably in a folder within the App_Config>Includes directory using a name such as “SolrCloudConfigs” to help organize your include files. This is for reading the Blog web index that users interact with on the CDs, so there is no SwitchOnRebuild as this is literally what the CDs use for returning SolrCloud based data for our custom Blog index.
<?xml version="1.0" encoding="utf-8" ?>
<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/" xmlns:role="http://www.sitecore.net/xmlconfig/role/" xmlns:search="http://www.sitecore.net/xmlconfig/search/" xmlns:database="http://www.sitecore.net/xmlconfig/database/" xmlns:environment="http://www.sitecore.net/xmlconfig/environment/">
<sitecore role:require="ContentDelivery" search:require="solr" environment:require="!Local" database:require="web">
<contentSearch>
<configuration type="Sitecore.ContentSearch.ContentSearchConfiguration, Sitecore.ContentSearch">
<indexes hint="list:AddIndex">
<index id="sitecore_blog_web_index" type="Sitecore.ContentSearch.SolrProvider.SolrSearchIndex, Sitecore.ContentSearch.SolrProvider">
<param desc="name">$(id)</param>
<param desc="core">$(id)MainAlias</param>
<param desc="propertyStore" ref="contentSearch/indexConfigurations/databasePropertyStore" param1="$(id)" />
<configuration ref="contentSearch/indexConfigurations/BlogSolrIndexConfiguration" />
<strategies hint="list:AddStrategy">
<strategy ref="contentSearch/indexConfigurations/indexUpdateStrategies/onPublishEndAsyncSingleInstance" role:require="Standalone or (ContentManagement and Indexing) or (ContentDelivery and Indexing)" />
</strategies>
<locations hint="list:AddCrawler">
<crawler type="Sitecore.ContentSearch.SitecoreItemCrawler, Sitecore.ContentSearch">
<Database>web</Database>
<Root>/sitecore</Root>
</crawler>
</locations>
<enableItemLanguageFallback>false</enableItemLanguageFallback>
<enableFieldLanguageFallback>false</enableFieldLanguageFallback>
</index>
</indexes>
</configuration>
</contentSearch>
</sitecore>
</configuration>
Rebuild Your Custom Indexes
With your SwitchOnRebuild, EnforceAliases, SolrCloud Collections/Indexes, and Sitecore Collections in place, it’s time to open the Sitecore CMS and rebuild your indexes as a test. You will also want to open SolrCloud to review the MainAlias switching the index it uses once a rebuild completes.
