SolrCloud SwitchOnRebuild Building the Wrong Collection

Blue/Green Deployment Issue

The deployment process doesn't always run as smoothly as expected, and some issues may rise. In my case, I recently worked on an Azure PaaS environment with SolrCloud and SwitchOnRebuild enabled, but faced a problem along the way. This blog post will introduce the problem and the steps needed to resolve it.

The Problem

The issue I encountered was that the full Sitecore Rebuild Index was clearing out the Active Collection rather than the Rebuild Collection.

One of the troubleshooting steps I wondered was: "Where does Sitecore keep track of MainAlias and RebuildAlias?"

I found that Sitecore keeps track of the MainAlias and RebuildAlias in the CORE database within the properties table. The following query is a quick way to find out the entries.

SELECT TOP (1000) [ID]
       ,[KEY]
       ,[VALUE]
 FROM [dbo].[Properties]
 where [KEY] like '%collection'

From the query, it looks like there are multiple queries of the same collection: four of which, our site name is under master and other four with our site name with a suffix under web. I had expected there to only be four entries in total.

It turns out our blue/green deployment to the CM web apps is causing Sitecore to lose track of what is active and what is rebuild. In Sitecore, the site name is a combination of the server and IIS application.

When looking in Azure KUDU, sure enough, the site changes to having a suffix or not depending on what is the live slot and what is the stage slot.

Solution

The solution was to specify an instance name for the CM environment. Even though we are only using one active CM at a time, setting the instance name will ensure that the entry of the active/rebuild collection key does not change on swapping live VS deploy slots.

<settings role:require="ContentManagement" env:require="Prod">
    <setting name="InstanceName">
        <patch:attribute name="value">YourInstanceCMProd</patch:attribute>
    </setting>
    <setting name="Publishing.PublishingInstance">
        <patch:attribute name="value">YourInstanceCMProd</patch:attribute>
    </setting>
</settings>

After applying the setting, and manually deleting the old entries in SQL, we got the expected 4 entries in total.

One thing to note is that you would want to have a unique name across all environments, otherwise you may encounter publishing issues e.g. YourInstanceCMProd, YourInstanceCMStage, etc vs YourInstanceCM across all your environments.