Category: Databases
Managed MongoDB in your account: replica sets, backups and upgrades
Your MongoDB in a replica set that survives the loss of a node, with backups that restore and upgrades from one version to the next, without nasty surprises.
- Where it runs
- In your account, in your name
- Backups
- With tested restores
- Updates
- Planned and documented
In short
MongoDB is a document database widely used in web and mobile applications. Administering it means answering for it being available, fast and recoverable. We set up three-node replica sets, backups with point-in-time recovery that we restore in tests, indexes, metrics, security and version-by-version upgrades, always in your account and for your own use.
What do we take care of?
MongoDB is easy to get running, which is why many installations are still as they were on day one: a single node, no authentication, backups taken by hand and a version that no longer receives patches. We bring it to a state that can survive an outage and an accidental deletion.
Replica set
Three nodes, a primary elected by vote and two secondaries kept up to date.
Backups and oplog
Consistent backups and a stored oplog to go back to a specific moment.
Indexes
Slow queries, execution plans and indexes that are actually used.
Metrics
mongodb_exporter in Prometheus: lag, oplog window, cache and connections.
Upgrades
From one major version to the next, rehearsed first.
Security
Authentication, per-application roles, TLS and a private network.
Why three nodes?
In a replica set, the primary is elected by a majority of votes. With three nodes, if one goes down, the other two are still a majority, elect a new primary within seconds and the application drivers reconnect on their own. With two nodes, losing one leaves the other without a majority and without writes. An arbiter saves a server, but it stores no data and complicates majority writes, so we prefer three data-bearing nodes. We also review the application’s writeConcern: with majority, an acknowledged write survives the loss of the primary.
| Situation | What we set up | Why |
|---|---|---|
| Development or data that can be regenerated | One node with off-site backups | No complexity, but no failover |
| Normal production | Three-node replica set on separate machines or zones | Survives the loss of a node without intervention |
| Data or writes that do not fit on one server | Sharded cluster | Spreads the load, at the cost of many more moving parts |
| You are already on AWS, Google Cloud or Azure | MongoDB Atlas | Less operations work; we review indexes, alerts and restores |
What problems do we come across most often?
- No authentication and open to the internet: the most common way to lose an entire MongoDB database.
- A single node in production: every server restart is an application outage.
- A short oplog window: a secondary that falls a few hours behind can no longer catch up and has to be fully resynchronised.
- Queries without an index: full collection scans that push the CPU up and empty the cache.
- Documents that grow without limit: arrays that pile up elements until they approach the 16 MB maximum per document.
- An unsupported version: several major versions behind, with a daunting jump still to make.
How do we take and test backups?
There are three ways and they are not equally good. mongodump is fine for small databases or for exporting a collection, but it is slow and restoring a large database can take hours. Disk snapshots are fast if they are taken consistently, with the journal on the same volume. For production we use Percona Backup for MongoDB, which takes physical or logical backups of the replica set and stores the oplog continuously, so you can recover to the minute before a deletion. Backups are sent encrypted to object storage in another account or with another provider. At least once a month we restore into a separate environment, check document counts and indexes, and note in the report how long it took.
How do we upgrade versions?
MongoDB can only be upgraded from one major version to the next: from 6.0 to 7.0 and from 7.0 to 8.0, with no skipping. At each step we upgrade the secondaries first, one at a time, then step down the primary and upgrade it. The application keeps working throughout. Afterwards we leave the featureCompatibilityVersion on the previous version for a few days, in case we need to roll back, and only raise it when everything is running well; without that step you cannot move to the next version. Beforehand we check that your applications’ drivers support the target version.
What about the licence?
MongoDB Community is released under the SSPL licence, which imposes conditions on anyone offering MongoDB as a service to third parties. That is why we always work the same way: the database is installed in your account or on your servers, for your applications, and we only administer it. We do not offer MongoDB as a service shared between clients. If the licence does not suit you, we can talk about Atlas or moving to another database, such as PostgreSQL.
How do we make sure everything is running well?
Alerts cover nodes that are down, replication lag and disk, as in SRE as a service. The metrics end up in monitoring with Grafana and Prometheus.
Where do we set it up?
In your account, with the provider you already use or the one that fits best. If the data has to stay in the EU, Hetzner and OVHcloud are the European options.
Providers we set it up on
- Hetzner
- AWS
- Google Cloud
- Azure
- DigitalOcean
- OVH
- Own server
| Provider | How we set it up | Things to bear in mind |
|---|---|---|
| Hetzner | Replica set on three cloud or dedicated servers, on a private network, with backups in Hetzner Object Storage. | There is no managed MongoDB at Hetzner: we look after the replica set, the backups and the upgrades. |
| AWS | MongoDB Atlas on AWS, or EC2 with a replica set spread across three zones and backups to S3. | Amazon DocumentDB is compatible with part of the API, but it is not MongoDB: we first check that your application does not use what it lacks. |
| Google Cloud | MongoDB Atlas on Google Cloud, or Compute Engine with a replica set and backups to Cloud Storage. | Google Cloud has no managed MongoDB of its own; the managed option is Atlas. |
| Azure | MongoDB Atlas on Azure, or virtual machines with a replica set across separate zones. | Azure Cosmos DB for MongoDB imitates the API with a different engine: it works in some cases and is worth testing with your queries. |
| DigitalOcean | DigitalOcean managed MongoDB with standby nodes, or Droplets with a replica set. | Convenient for small and medium workloads; we check the version, size and backup retention of the plan. |
| OVH | OVHcloud managed database for MongoDB when it is available in your region, or Public Cloud instances with a replica set. | We first check which MongoDB version it offers. |
| Own server | Replica set on three of your servers or virtual machines, with the backups on external S3 storage. | Three nodes on the same physical host are not high availability: if that host goes down, everything goes down. |
What is included
- Three-node replica set on separate machines or zones, with priorities and elections reviewed.
- Backups with Percona Backup for MongoDB or consistent disk snapshots, and an archived oplog for point-in-time recovery.
- Regular test restore in a separate environment, with the time measured in the report.
- Review of slow queries with the profiler and explain, and indexes that cover them.
- Metrics with mongodb_exporter and alerts on replication lag, oplog window, disk and connections.
- Upgrades from one major version to the next, with featureCompatibilityVersion under control.
- Authentication enabled, one user per application with minimal roles, TLS and access only from the private network.
- Migration plan from MongoDB Atlas, or to Atlas, if that is what suits you.
Frequently asked questions
What licence does MongoDB have and does it affect us?
MongoDB Community is released under the SSPL licence. Using it within your own company, as the database for your applications, is not a problem. That is why we always install and manage it inside your account and for your use; we never offer it as a service shared between clients.
Atlas or MongoDB on our own servers?
Atlas takes patches, backups and failover off your hands, and is usually the sensible choice if you are already on AWS, Google Cloud or Azure and the database is medium-sized. Running it yourselves pays off when Atlas gets expensive with volume, when your provider does not offer it, as with Hetzner, or when you want the data on servers you control.
Can we migrate from Atlas without stopping the application?
Almost. The new replica set is prepared with the same version, the data is copied and kept in sync with a continuous synchronisation tool while you test. The cutover comes down to changing the connection string. Beforehand we check that you do not use Atlas-only features, such as its built-in search.
Do we need sharding?
Hardly ever at the start. A well-sized replica set with good indexes copes with far more than people tend to think. Sharding adds config servers, routers and a shard key that is hard to change; we only propose it when the data or the writes no longer fit on one server.
What about Percona Server for MongoDB?
It is a distribution compatible with MongoDB Community that adds hot backups, auditing and LDAP authentication out of the box. It has the same SSPL licence, so nothing changes in that respect; we propose it when you need those features without moving to the paid edition.
Tell us about your case
In a free 20-minute call we look at where you are and where to start. No commitment.
Official documentation consulted
The technical details on this page are based on:
Reviewed on