MongoDB will introduce new element into infrastructure of your solution. This increases cost of servers, cost of maintenance and at the end complicates the overall solution landscape.
In scaled solution you would need couple of Mongo DB server e.g. replica sets to support failover, redundancy and data availability.
If you stay with MS ...
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 ...
Sitecore recommends here the minimum hardware for planning an xDB with Session State as follows:
2 Collection database (MongoDB) servers
4 x CPU E5 2650 v2 processors
16GB RAM (the more the better)
100GB SSD disk
In addition to that, I would recommend a separate disk for the Operating System, and leave the 100GB SSD disk just for the collections.
I know you have already found the exact solution for your particular case. Still, I'm going to list the steps I normally take when troubleshooting data saving issues in xDB. Hopefully, this can help others in the future.
Ensure the analytics connection string is set up properly in the ConnectionStrings.config.
Make sure that you have a valid xDB license. ...
As EXM does not support CMS-only mode, xDB is required to run EXM. See the documentation on all the components that require xDB.
When you send an email campaign, the Email Experience Manager (EXM) creates an interaction in the Sitecore Experience Database (xDB) for each of the following email events:
Sent – one interaction for every sent email message.
To answer your question, really, I feel it's prudent to walk through
the deployment steps and call out where places that might be gotchas.
I'll finish with a summary of what I would do.
Sitecore 7.5 - 8.0 Initial (141212)
The first step that you'll want to do is upgrade to the 8.0 Initial release. You can find the Upgrade Guide here. During this ...
There are several things which doesn't work properly anymore. You can disable it in the config. Go to /App_Config/Include/Sitecore.Analytics.config and set Analytics.Enabled to false:
<setting name="Analytics.Enabled" value="false" />
You also need to comment out all MongoDB connection stings:
<add name="analytics" connectionString="mongodb://...
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 ...
Sitecore provides the xDB Data Conversion tool that supports xDB data conversion. This tool will help you in migrating the data from Sitecore Experience Database 8.x to Sitecore Experience Database 9.0.
You can download this tool from https://dev.sitecore.net/Downloads/Sitecore_Experience_Platform/90/Sitecore_Experience_Platform_90_Initial_Release.aspx
Sitecore-specific replica set considerations
Your question is partially answered here:
What are the best practices for MongoDB replica set latency?
That question discusses how latency affects a replica set and how to set it up properly for xDB.
As a short summary, you should set up xDB to only read from the primary node of your replica set. This will ...
Nonlinear Digital did a little rule of thumb for 7.5, I guess it still holds true(ish) now - they said:
"As a basic rule of thumb, Sitecore calculates diskspace sizing projections using 5KB per interaction and 2.5KB per identified contact and these two items make up 80% of the diskspace"
So if an interaction is essentially a user session you should be able ...
Utilizing data extension points
The first thing I would consider is whether your data can be stored as part of the standard Sitecore entities.
The xDB contact has the following fields where you can store custom data that will be saved to MongoDB:
If you use any of the above, you won't have to ...
If your throughput consist out of more than 100.000 writes per second, I would recommend you use an SSD. I think you should not overkill your machine. MongoDB cache will only take up to 10% of your available RAM to cache it's write actions. When you use the write concern w:majority on a replicaset your data will always be present in at least 2 (if you have a ...
You mentioned in comments that you're getting an error—this is because there is no tag in my docker hub repository. I wouldn't know which version of Sitecore latest should be build against: 8.2 or 8.1 update 3, and on the top of that, which version of SolR. So I choose to go with the tag 8.2.
So you would have to pull it with the following command:
I have experienced both of the errors that you mention in an 8.1.2 instance - sometimes together and other times separately. The below are the most common causes and solutions for these issues, in my experience.
Note that it is possible for you to have more than one of these issues at a time.
Tracking and xDB Disabled...
The Tracker.Current is not ...
Here's my understanding (from notes taken during a Mongo engagement a while back): for MongoDB, the more RAM the better. MongoDB performs everything in memory (by default) and flushes it to disk in a separate thread. An SSD drive will speed up the flushing process. Note, unless you force MongoDB to acknowledge writes only after you physically write to a ...
In general, if your data nodes are hosted in different geographical regions, latency between them will be considered high.
High latency will make the replication process slower, which means that using the write concern of w:1 is highly recommended in order to prevent performance degradation. On the other hand, if the majority of your nodes ...
Currently, for enterprise installations of MongoDB, the Sitecore Best Practice for Disaster Recovery of Mongo rests solely on the Best Practices of MongoDB specifically and are not entirely different for Sitecore applications.
That being said... there are some things to consider:
Answering Your Specific Question
Are people architecting their solutions ...
I'll use some common sense from another post that I saw here that was about Sitecore 8.2 does not officially support Windows Server 2016 but is it compatible in reality and will it work in production?
Using Mark Cassidy words
It comes down to support
Based on that, I don't think Sitecore wouldn't work with MongoDB 3.2.n - where n goes from 1 to 16 - ...
Yes - there are several advanced ways this can be used - but as I see it the main drawback will be that you expose yourself to a heavy denial of service attack.
The in-memory provider will block writes and therefore hinder creations of new sessions if it runs out of memory - so a session flood attack (probably the easiest attack there is) will bring your ...
Personally I've always seen and treated Solr as a transient index, not a persistent storage solution. Whereas MongoDB has always been treated as a storage solution, and not much of an index. But this is my personal treatment, not saying that Solr can't be used as a persistent store.
If you need to access the data directly as Key/Value pairs and there isn't ...
The package was renamed on nuget, what you want is the mongocsharpdriver package. You can get 22.214.171.124 by using:
Install-Package mongocsharpdriver -Version 1.10.0
That package contains boths MongoDB.Driver.dll and MongoDB.Bson.dll.
Here is the nuget page for the older project:
Which has now been ...
Basically, it is a kind of difficult sometimes to query the MongoDB directly, I had a similar scenario and following what I did:
I created aggregation processor that will be called when you rebuild the analytics database or when aggregation occurs:
public class PageEventProcessor : AggregationProcessor
protected override void OnProcess(...
Grant Killian wrote on his blog about using MongoDB TTL (Time to Live) Indexes to continuously purge xDB data based on an interval.
The crux of the post that pertains to this:
MongoDB supports “Time to Live (TTL) Indexes” which purge data based
on time rules. Data older than 1 week, for example, could
automatically be removed with this index type.
The issue that you are seeing is because you are trying to instantiate a new ContactRepository().
The appropriate way to reference the repository is by creating the object through Sitecore's Configuration Factory.
private ContactRepository _repository = Sitecore.Configuration.Factory.CreateObject("tracking/contactRepository", true) as ContactRepository;
You can access MongoDB directly through the C# driver:
string connectionString = ConfigurationManager.ConnectionStrings["analytics"].ConnectionString;
var client = new MongoDB.Driver.MongoClient(connectionString);
var database = client.GetServer().GetDatabase("your_database_name");
var contacts = database.GetCollection("Contacts");
var results =
It saves at sessions end because when the contact owner is on the site, the contact is locked in xDB. You couldn't save it if you wanted to. You have to wait until it is saved and the contact is released. This is the major flaw with xDB and the reason xConnect was created.
In 9.0 xConnect resolves this by making the contact separate from the session. You ...
Yes, you can disable xDB.
You need to add a patch file Xdb.Enabled and Xdb.Tracking.Enabled set to false:
Ensure the VisitorIdentification code is available on the layout.
Also, if it helps, the contact creation logic is executed in the below pipeline processor:
<processor type="Sitecore.Analytics.Pipelines.EnsureSessionContext.CreateContact, Sitecore.Analytics">
I have solved this issue. It was due to following the recommended enable/disable configuration guide (https://doc.sitecore.net/sitecore_experience_platform/setting_up__maintaining/xdb/configuring_servers/configure_a_content_management_server), which tells me to disable the following config files for a CM instance (this was occurring on a test environment ...