MongoDB Support and Consulting

The replica set is the basis of availability in MongoDB #

High availability in MongoDB is provided by the replica set. Within the set one node takes write traffic as the primary while the others copy the data as secondaries. When the primary becomes unreachable, the remaining nodes hold an election and choose a new primary. For the election to conclude, the number of voting members has to be odd; in production that means three data nodes.

An installation with two data nodes and an arbiter looks at first like the same job done more cheaply. The arbiter votes but holds no data. When one data node is lost, a single copy remains, and applications using majority write concern can become unable to write. On systems with a low tolerance for data loss we do not recommend an arbiter.

The real decision in the installation is not the node count but setting two values from what the application needs:

• Write concern. The majority value keeps a write from returning success until it is confirmed to have reached a majority of the nodes; it prevents data loss at the moment of failover and increases write latency in return.
• Read preference. Routing read traffic to secondaries relieves the primary, but a secondary returns stale data for as long as it lags in replication. Flows that need read-after-write consistency have to stay on the primary.

On the operational side the value we watch regularly is the oplog window: it determines how long a secondary can stay unreachable before it is forced into a full resync. As the window narrows, so does the time left for maintenance work.

The sharding decision starts with the shard key and ends there #

Sharding is the distribution of data across more than one replica set. The application connects to the mongos router; which document sits on which shard is held on the config servers, which run as a replica set of their own.

The single decision that determines the whole architecture is the shard key. The key settles how documents are distributed across shards, and whether a query goes to one shard or to all of them.

The mistake we see most often in the field is choosing an ever-increasing field — a timestamp or an auto-incrementing id — as the key. Because every new document falls into the same range, write traffic piles onto a single shard; while the other shards sit idle, the system behaves like a single-node installation. At the other extreme, a key that distributes entirely at random evens out the writes but spreads range queries across every shard.

The right key is chosen by looking at the application’s query pattern. That is why we always start sharding work by establishing the query profile.

On current versions resharding a collection is possible, but the operation needs time and resources in proportion to the data volume. A key chosen correctly from the start is cheaper than any later correction.

The question to ask before sharding #

On a significant share of the systems that come to us asking to move to sharding, the real problem is not scale. Before the decision we take three measurements:

• Does the working set fit in memory? MongoDB keeps frequently accessed data and indexes in the WiredTiger cache. Once the working set exceeds memory, every query goes to disk and response times rise several fold. Building sharding while the system is at that point amounts to copying the problem onto more servers.
• Is the index design right? A query doing a collection scan because of a missing index occupies more nodes as the shard count rises.
• Does the write load really saturate a single node? The source of write latency is usually not node capacity but disk concurrency, or an excessive number of indexes being updated on every write.

If the answers to those three call for sharding, we build the architecture. If they do not, we recommend the much cheaper fix.

Index and schema design is a performance subject #

The basic rule of index design in MongoDB is the prefix behaviour of compound indexes: an index can only be used for an uninterrupted leading portion of its fields. We order the fields by equality, sort and range — first the fields matched exactly, then the field sorted on, and last the field with the range condition. Get the order wrong and the index goes unused even though it exists, and the explain() output shows that plainly.

On the schema side the decisive choice is between embedding related data in the document and keeping it in a separate collection with a reference. Embedding brings all the data in a single read and removes the need to join; in return the document is rewritten whole on every update, and embedding an array that grows without limit runs into the document size limit. Separating gives flexibility, and increases the number of reads in return.

The choice between the two is made from the access pattern, not from the data model. A schema decision made without measuring which data the application reads together is the kind of decision that later requires a data migration.

Distribution choice: Community and Percona Server for MongoDB #

MongoDB Community Edition is enough for most installations. The two components corporate audits ask for are not present in it: audit logging and encryption at rest.

When that need arises, the route we recommend is not to buy a commercial licence but to move to Percona Server for MongoDB, built on the same core. Audit logging, encryption, hot backup and LDAP authentication come with that distribution at no additional licence cost. The change requires nothing on the application side; the drivers and the queries stay the same.

We have no commercial relationship with Percona. What we provide is the installation and configuration of the distribution and the operational maintenance that follows.

MongoDB support on managed cloud services #

We support organisations using MongoDB Atlas. On a managed service the infrastructure, the backups and the version upgrades are the provider’s responsibility; schema design, index strategy, aggregation pipeline optimisation and the shard key choice stay with the organisation. Most of the support need is already under those headings.

Amazon DocumentDB is a separate product, and that distinction needs to be understood. It is compatible with the MongoDB API but is not MongoDB itself; the feature set it supports and the way it behaves differ. On systems running on DocumentDB we first measure which features are genuinely usable, and report the incompatibilities.

How we work #

We connect to your systems remotely under a non-disclosure agreement (NDA). We define only the privileges the work requires for the database user, and we record every change we apply.

When we take on a system for the first time, we establish the current state: the version and configuration inventory, the replica set topology and the oplog window, the index inventory and usage rates, the relationship between the working set and memory, and the state of backup and restore. The recommendations are built on that measurement.

Related services #

We carry out the same work for MySQL, PostgreSQL and MariaDB: MySQL Support · PostgreSQL Support · MariaDB Support

Send us your MongoDB support request