This topic provides an example of the standard approach to configuring MongoDB when you install the Sitecore Experience Database (xDB) with MongoDB as your collection database. This example includes the minimum possible number of MongoDB instances in a single replica set while still ensuring that replication is in place. This setup consists of three Azure virtual servers: one primary and two secondary.
All production deployments should use replication to provide redundancy and increase data availability. Replication copies data to multiple servers, so if one server fails no data is lost. You can place servers in different geographical regions, defaulting to one and using the other as backup for disaster recovery (DR) or high availability (HA) failover.
Depending on how you configure MongoDB, you can increase read capacity by setting the priority on each instance. The primary is the only member of a replica set that can receive write operations. You set priority by allocating a number to each instance, the highest number gets top priority.
In the example in this topic, the member with priority 10 will always be elected the primary if it is available. The other member with priority 9 will be secondary. If you have an arbiter this has no priority setting, as it can never become the primary (it does not store data and its only real use is for voting during elections). Similarly, a data member with priority 0 will never become primary, though it still maintains a copy of the data and can serve reads if the appropriate read preferences are used.
If the primary becomes unavailable for any reason, MongoDB performs an election to determine which member becomes the new primary. Only members that have a value higher than zero (0) can take part in elections and there must be a majority vote.
You can use priorities in many other useful ways, for example, to give priority to nodes with the most powerful hardware or to give priority to the primary data center.
You should not set priorities just to make it more predictable which node will become the primary because this can result in making operations more complicated. This information can easily be discovered using the
Refer to the MongoDB documentation for more information on replica sets, setting priority, and elections: MongoDB replication
The Collection Database (MongoDB) diagram shows an example of a standard MongoDB replica set implementation on three servers (3 data nodes). For reliability and resilience, you should have 3 data nodes (1 primary, 2 secondary), especially if write concern w=majority is used (to avoid rollbacks) and during periods when one of nodes are unavailable (for example, during maintenance, upgrading, or defragmenting).
As the collection database grows, you will find that you need more storage space. You might also find that read and write speeds slow down. In MongoDB there are different ways of configuring your environment to cope with these demands. Sharding enables you to scale horizontally. This means adding more computers to store data and spread the load, which can also help to improve read capabilities, write speeds, and contributes to generally improved performance.
For more information on installation, replication, and the different configuration options available in MongoDB, see the MongoDB website.