0

Sitecore 8.1 rev 160302.

I've inherited a website that I'm having issues with the indexes. There is 1xCM server and 3xCD servers. We're using Lucene so have separate versions of the indexes on all 3 CD servers.

The problem is, none of these are sync'd up. Looking at the data in Luke: sitecore_web_index: CD1: 564 docs, last mod 29.03, CD2: 426 docs, last mod 27.03 etc..

Our custom index is the same - different numbers of records on different servers and wildly different modified times. On CD2, the index hasn't even been built!

I think the culprit might lie in the scalabilitysettings.config which is enabled but the InstanceName is empty. This is true certainly for one of the CD servers. I can't get access to look at the other two, but I'm guessing if they're the same, then it might lead to this issue? HOWEVER, I thought if it was empty, Sitecore would generate an instance name of [machinename]-[iis-sitename]??

The only other weirdness I can think of is that they publish to "pub" (which points to web). If I change the content editor to web after a publish, I can't see the items in the tree (even if I manually clear caches), whereas if I switch to "pub", I can!

If it does boil down to instancename, then I can probably jump through some hoops to get that changed, but I have a nagging little bell in the back of my head that this causes other issues? I might be wrong, but I'm sure I've updated it on a previous project and something blew up?!

Any help appreciate. Thanks

UPDATE

I've managed to compare the configs and the plot thickens, although it's added to the confusion:

CM has pub and web setup in connectionstrings. web is pointing to SQL1 pub is pointing SQL2.

The CD servers are pointing SQL2. On authoring we publish to pub, so changes show up in the delivery environment.

However, onpublishAsync on the CM is pointing to web (SQL1). So, I guess nothing is going into correct eventqueue (the one the CD servers will be pointing to). The question now is, how is anything being indexed?

  • What about PublishingInstance setting. Do you have anything set? – josedbaez Mar 29 at 15:22
  • @josedbaez - no, nothing in that for this file certainly. Looks like they've just taken the .example extension off the vanilla install file :-/ – stuartw87 Mar 29 at 15:32
  • Can you check if the eventqueue setting is set to true? For scalability settings, you can refer to my post here: hishaamn.wordpress.com/2016/03/19/sitecore-scalability-setting – Hishaam Namooya Mar 29 at 16:03
  • Hi @HishaamNamooya, yes, when I was on the boxes, I did check that setting and it was true for the CMs and the CDs – stuartw87 Mar 29 at 16:06
  • As Pete pointed out below, Lucene is not recommended, however, it can typically get close. Though the results are rarely identical, you should have roughly the same number of docs per index. In your case, I would start by verifying the configs on all 3 CD servers are nearly identical (nearly because there may be some elements that intentionallly differ). I've seen a similar situation with distributed Lucene indexes and the culprit one server had slightly different config settings (and in fact was erring). – jrap Mar 29 at 16:53
2

Sitecore has been very specific that Lucene should not be used in scaled out environments. This is because every CD may have a different index, and demonstrate the issue that you are reporting. Sitecore's own documentation says:

You must use Solr if you have a scaled environment.

The recommendation to fix this issue is to install Solr and have all CD's reading from the same index.

Instance Name in Multi-CD

As you note, the ScalbilitySettings.config for InstanceName, when set to empty does indeed use <machinename>-<sitename> as a default value. As long as all of the CD's are using a different machine name and/or sitename, then the EventQueue should be correct.

  • Thanks Pete, I'm aware of the best practice around around the indexing, and if I could implement SOLR, it would be done, but it just isn't an option. It'll take months of wrangling just to get this into the test environments, let alone prod :-( In terms of fixing this for the here and now, do you think adopting the remoteRebuild indexing strategy might work? – stuartw87 Apr 1 at 8:04
  • I think it might work, but understsnd there's no guarantee that the CD's will always be in sync. – Pete Navarra Apr 1 at 13:14

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.