10

We are building an infrastructure for xDB internally and our internal network team asked us what would happen if the MongoDB instances were down.

We, of course are deploying MongoDB with Replica set but they want to be sure it will not bring down the site.

I remember from somewhere that Sitecore will cache the entries locally on the CD instances until the MongoDB comes back online and then once up, it will sync. Is this true?

3

4 Answers 4

15

It's also important to know that while Mongo is not available, analytic data is being collected. Sitecore will store the data to the file system until such time the collection server comes back online.

From Akinori Taira @ Sitecore:

In the event that the collections database is unavailable, there is a special ‘Submit Queue’ mechanism that flushes captured data to the local hard drive (the ‘Data\Submit Queue’ folder by default). When the collections database comes back online, a background worker process submits the data from the ‘Submit Queue’ on disk.

Sitecore 7.5 and 8 have a key in the Sitecore.Analytics config that can control Sitecore's behavior if Mongo is unreachable for any reason (best I can tell, this has been removed as of 8.1):

<setting name="Analytics.FailOnDatabaseErrors" value="false" />

The submit queue is enabled/disabled from the Sitecore.Analytics.Tracking config file's UseSubmitQueue key:

 <!--  ANALYTICS USE SUBMIT QUEUE
        Specifies if the submit queue should be used when the contact or session submit operations cannot access the database.
        If set to true, the contact or session is queued until the database is backed up (see the <submitQueue> section).
        Default: true
  -->
  <setting name="Analytics.UseSubmitQueue" value="true" />

The background task that will flush this to Mongo is configured in the Sitecore.Analytics.Tracking.Database.config's SubmitQueue node:

<submitQueue>
  <backgroundService type="Sitecore.Analytics.SubmitQueueService, Sitecore.Analytics">
    <!-- Service wakeup interval in seconds. -->
    <Interval>60</Interval>
  </backgroundService>
</submitQueue>

Other reading/Sources:

Sitecore Climber answered this quite well here: https://stackoverflow.com/questions/39153295/in-sitecore-how-to-view-the-content-of-the-submit-queue-file

And LonghornTaco's great blog post on this subject: https://citizensitecore.com/2016/07/01/xdb-session-info-and-mongodb-availability/

5
  • 2
    Yes this is what I was looking for. I reached out to a few guys about this. Thank you.
    – ASura
    Oct 20, 2016 at 17:57
  • You are welcome to copy more details from the links you provided—e.g. about the available configuration settings of the submit queue (the behavior of the site will vary based on their values). Answers on this site need to be complete on their own, with external links only used to provide additional information. See meta.stackexchange.com/questions/8231 Oct 20, 2016 at 18:01
  • 1
    @DmytroShevchenko Will do, I'll flesh this out further.
    – Derek C
    Oct 20, 2016 at 18:07
  • Note that the setting Analytics.FailOnDatabaseErrors also affects site behavior when MongoDB is down. Oct 20, 2016 at 18:21
  • @DmytroShevchenko Nice catch! I neglected to mention it since it's gone from 8.1 on, but I should reference it.
    – Derek C
    Oct 20, 2016 at 18:27
10

If the collections database is unavailable, analytics data for a user's session will still be collected and stored in Session. The problem comes when the session times out and Sitecore attempts to flush that data from Session to the collections database.

From Akinori Taira, part of the xDB product team:

In the event that the collections database is unavailable, there is a special ‘Submit Queue’ mechanism that flushes captured data to the local hard drive (the ‘Data\Submit Queue’ folder by default). When the collections database comes back online, a background worker process submits the data from the ‘Submit Queue’ on disk.

As with most everything else in Sitecore, this mechanism is controlled by entries, scattered across a few config files.

In Sitecore 8.0 (and its updates) there is a setting called Analytics.FailOnDatabaseErrors in Sitecore.Analytics.config:

    <!-- ANALYTICS FAIL ON DATABASE ERRORS
Note: This is a diagnostics setting that should not be enabled on a live system.
If set to true, web pages crash and show exception details in case
an operation cannot access the database.
If set to false, exceptions are suppressed and logged, and visit data
is queued until the database is back up. See <submitQueue> section.
Default: false
-->
<setting name="Analytics.FailOnDatabaseErrors" value="false" />

However, in Sitecore 8.1+, the property Analytics.UseSubmitQueue is used from Sitecore.Analytics.Tracking.config:

<!--  ANALYTICS USE SUBMIT QUEUE
    Specifies if the submit queue should be used when the contact or session submit operations cannot access the database.
    If set to true, the contact or session is queued until the database is backed up (see the <submitQueue> section).
    Default: true
-->
<setting name="Analytics.UseSubmitQueue" value="true" />

Finally, from the Sitecore.Analytics.Tracking.config and Sitecore.Analytics.Tracking.Database.config, you get the following:

<submitQueue>
    <queue type="Sitecore.Analytics.Data.DataAccess.SubmitQueue.FileSubmitQueue, Sitecore.Analytics" singleInstance="true" />
    <backgroundService type="Sitecore.Analytics.SubmitQueueService, Sitecore.Analytics">
        <!-- Service wakeup interval in seconds. -->
        <Interval>60</Interval>
    </backgroundService>
</submitQueue>

I have not tested this failover scenario myself yet, so your mileage may vary.

3

If you are about to build a Replica Set based on MongoDB recommendations which says

Three member replica sets provide enough redundancy to survive most network partitions and other system failures

The chances to get MongoDB down will be reduced.

However, just in case an incident happen, the standard configuration for a Replica Set is to provide a level of fault tolerance against the loss of a single database server. And in addition to that, the Secondary will be able to reply the requests until you get the primary back to business.

2
  • Thank you this is helpful. Was looking for an instance where everything will be down. We are planning on having two shards each containing a replica set. This was an edge case we had to provide information on.
    – ASura
    Oct 20, 2016 at 18:04
  • Glad to be useful! :) Oct 20, 2016 at 18:05
2

Below is the 1 main points I know if MongoDb is down, the following occurs

  1. Package installation will take too much time to install.

However, it will not bring the site down unless you are querying the MongoDB directly. You may receive error page on the specific page where the query to MongoDB is being executed. Moreover, in order to prevent this, you can make MongoDb run as a service or run it through Sitecore pipeline. Below is the link how you can run MongoDB in Sitecore pipeline

https://blog.istern.dk/2014/10/01/launch-mongo-db-with-sitecore-pipelines/

2
  • 2
    Actually, analytics of a current session WILL be tracked if xDB is unavailable. It will be stored in session until the session end event is fired. If xDB is unavailable at that time, it will get stored on disk until xDB comes back online. Oct 20, 2016 at 18:09
  • Yeah, I will update the answer as i wasn't aware of it Oct 20, 2016 at 18:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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