2

We are running Sitecore 9.0.0 (Initial Release) on Azure with SolrCloud (6.6.2) and getting close to go-live.

We are using Sitecore's SwitchOnRebuild functionality for indexing so that the indexes should be refreshed in the background. However, we are seeing an issue with the swapping of those indexes which means that the indexes are not updated correctly and various 404 errors are presented to the end-user because of failed lookups.

We can also see clear differences between the index and rebuild indexes via a direct query in Solr.

Initially, Sitecore thought this was a timeout issue (because there was a clear error in the logs relating to this) and we've increased the period from the default to 30 minutes. We are no longer seeing the timeout.

We are also using EnforceAliasCreation and have multiple SolrCloud nodes, both of which are highlighted as potential causes of this behaviour and fixed in 9.0.2. Sitecore has suggested however that the release notes on these two issues are misleading.

Has anyone seen/solved this before? Or any general pointers would be greatly appreciated - Sitecore support seem a bit stumped so far.

  • 1) SwitchOnRebuild means that when you finish full index rebuild Sitecore swaps indexes: that is currently in use and "rebuild" index 2) When you do index update, or any publish(or interval strategy) causes index update then only one index is updated. "Rebuild" index is not touched. It means that Sitecore SwitchOnRebuild index behaves like default with only one change, on index rebuild it works with "rebuild" index to avoid breaking of index during indexing. And it is default Sitecore+Solr SwitchOnRebuild index behavior. Can you list steps, what do you do and actual and expected results? – Anton Jul 6 '18 at 12:46
  • Hi @Anton thanks for the quick response, this has currently escalated quite high in with Sitecore support so I won't waste anyone's time looking for anything too simple but will report back when we get some sort of resolution and will provide more commentry around the root cause then – Steve Newstead Jul 6 '18 at 13:38
  • What happens if you set EnforceAliasCreation to false and then test? Can you let us know if aliases are created everytime a rebuild happens or only on app pool recycle or iis reset? I have faced similar issue in the past and setting alias creation to false seemed to fix it. This has been a problem for atleast 3 years now . You are not new to this problem. – Gabbar Jul 10 '18 at 23:10
  • I came across this same problem with Sitecore 8.2 Update 4 and Solr 5.5.5. Apparently, the EnforceAliasCreation property should only be used the first time and then never be used again so should be set to false after that. Or you could create the aliases yourself manually. WIth EnforceAliasCreation set to true, check the aliases before and after index rebuild using this URL in solr - /admin/collections?action=CLUSTERSTATUS. – Gabbar Jul 25 '18 at 2:19
  • Everytime the app pool is reset or IIS restarted, aliases creation is re-run and from what I noticed, So this setting set to false is what should be correct usage. BTW, what did Sitecore say? – Gabbar Jul 25 '18 at 2:40
3

Okay - so we've got to the bottom of this and it looks like it was just a misconfiguration issue when using SOLR cloud.

I'm posting this here for reference:

Rebuilding the index for SOLR cloud is detailed here

With the most important things being:

On the CM box the following should be setup:

<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>

But on the CD boxes, it should be configured like this:

<index id="sitecore_web_index" 
type="Sitecore.ContentSearch.SolrProvider.SolrSearchIndex, 
Sitecore.ContentSearch.SolrProvider">
       <param desc="name">$(id)</param>
       <param desc="core">$(id)_MainAlias</param>
       <param 
ref="contentSearch/indexConfigurations/databasePropertyStore" 
desc="propertyStore" param1="$(id)" />

Where we'd gone wrong was that the on our CD box was pointing at sitecore_web_index and not at value in .

So from the example above it should have been sitecore_web_index_MainAlias

When we did this everything worked as expected. Obvious now, but the docs are not that clear on the configuration of the CD boxes so worth posting here in case it helps anyone else.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.