Self-managed MongoDB replica sets

Run MongoDB 8.0 replica sets on your own Linux servers, on Percona Server for MongoDB, with majority writes by default, physical backups with point-in-time recovery from the oplog, and every change planned and approved like any other cluster.

Replica sets, as MongoDB intends them

High availability comes from MongoDB’s own replica-set elections. ElastiCluster creates the replica set, keeps its members configured and watches it, but does not sit between your application and the database: drivers get the replica set’s seed list and find the primary themselves, so there is no proxy layer.

Single: a one-member replica set, so transactions, change streams and point-in-time recovery work from the start and it can grow later.

Replica set: three to seven data-bearing voting members, three or five recommended, spread across zones.

No arbiters in v1.0, because an arbiter weakens the default write guarantee. Arbiters, hidden and delayed members, and sharded clusters are planned for v1.1.

The distribution is Percona Server for MongoDB, chosen for its hot-backup cursor and log redaction. MongoDB 8.0 is the default; 9.0 follows once Percona ships it.

Durable by default

Writes default to majority acknowledgement. Choosing the relaxed setting is possible, and lower write concerns are counted and reported rather than hidden. A new replica set starts without a network listener and is initiated exactly once, and a member whose data belongs to a different replica set refuses to join.

With three or more data-bearing members and drivers that retry writes, the failover target is at most 30 seconds from detection to the first successful write, with election timers of 10 seconds by default. If a majority of members is lost for good, recovery is a forced reconfiguration that needs approval and states what may be lost.

Connecting

The Connect page gives a connection string with the replica-set name and TLS on, optionally as a mongodb+srv seed list whose DNS records you create. TLS cannot be disabled, because members authenticate each other with certificates. Allowed clients are enforced by the firewall and by per-user address restrictions.

Backups and point-in-time recovery

Physical hot backups stream from the server, compressed and encrypted, straight to your repository, with a full backup weekly and incrementals daily. Two independent archivers copy the oplog, only for majority-committed entries, closing a segment every five minutes. Restores go to a new cluster by default, to a time, an oplog timestamp or a restore point, and can restore selected databases. Drills compare document counts with the backup manifest and validate a sample. A manual restore with standard tools is tested on every release.

Day-2 operations

Switchover by stepping the primary down with catch-up; forced step-down as a high-risk plan.
Rolling restarts and minor upgrades; adding, removing and re-initialising members.
Major upgrades in two plans: a rolling binary upgrade, then a separate finalize step that raises the feature compatibility version and is the point of no return.
Certificate rotation online, and credential rotation with a single or dual user.
Users with owner, read-write and read-only presets; custom roles in v1.1.
A document workspace with find, aggregation and explain, read-only on a secondary by default, plus slow-query insights, current operations and unused indexes.

Before you plan a cluster

MongoDB needs CPUs with AVX, and some Linux kernel releases are refused by the preflight checks because of a known issue; today that includes the kernels shipped with Ubuntu 26.04. Transparent huge pages are set for MongoDB only on servers that run nothing else.

Status

MongoDB replica sets are planned for v0.4, together with Valkey and Dragonfly. In the demo, the “MongoDB loses a majority” scenario in Demo controls shows the approval-gated recovery. MongoDB is a trademark of MongoDB, Inc.; ElastiCluster manages MongoDB replica sets and is not affiliated with MongoDB, Inc. or Percona.