MongoDB, from one server to a sharded cluster, without leaving Vigia.

Everything on this page is Vigia doing the work on real servers — a test fleet of nineteen boxes across Rocky, Alma, Debian and Ubuntu. Nothing is a mockup: a replica set, its TLS and its updates, then the set grown into a sharded cluster, backed up, dropped and put back.

A real sharded MongoDB cluster over nineteen servers, every wire proved
/ THE REPLICA SET

A replica set, from its first two minutes on.

Built, encrypted between its members, updated with no downtime, proved wire by wire, and run day to day — every step of it from Vigia.

A replica set in two minutes.

Name the set. Drag three servers from the tree onto the members table — each is read as it lands: a shell opened with its saved login, what it runs, whether MongoDB is there. Give each member its role. Review the filing and press Apply. One job on every box at once: keyfile, bind, port, checked restarts, every wire proved from the box it starts at, then the set initiated from the primary. Two minutes later it is live and syncing a gigabyte.

TLS between the members, with Vigia as the authority.

Encryption between members is a must, so it is one button. Vigia is the set's certificate authority — its key never leaves your computer — and it walks the mode up on every member, allow to prefer to require, with no downtime. Renewal needs no restart. Apps are untouched; only the members' own stream is bound.

Linux updates on a live set, with no downtime.

A member of a set never gets Update or Restart on the map — an upgrade restarts mongod, and restarting a member out of order is a failover nobody planned. The set's own page walks it safely: secondaries first, each rebooted and reconnected before the next, the primary stepped down last. The apps on a replica-set connection string never notice.

The set on the wire, and on paper.

The canvas draws every member and every wire between them on the engine's port, in both directions, and proves each one from the box it starts at — reach measured on the source, listen and allow read on the destination. Red is broken, with the reason on the wire. The same reading goes on paper: a report of the set as every member sees it, the firewall of every member as one table, the versions, the wires proved — drawn on screen and, for the person without Vigia, one PDF.

Day to day: the numbers, the data, the set.

Operations per second by kind, connections, the cache, what is queued, the lag of every member — sampled every two seconds while you look, with a trace that keeps sampling after you leave. The Explorer is Compass without leaving the console: a filter in mongosh's own syntax, documents edited as text, a pipeline, the schema sampled, the planner asked. And the set's own verbs on its page: step down, rolling restart, rolling upgrade, the oplog resized on every member, compact walked member by member.

/ SHARDING

Sharding: the set becomes a cluster.

A sharded cluster is replica sets stacked. The builder is drop boxes — config servers, shards, the app boxes that get a router — and one job puts it together. This is the whole conversion, as it went on the test fleet.

New boxes are read before anything starts

Drop a server that has no MongoDB and Vigia says so and offers the install at the cluster's version. A box whose login came in with a key asks for its sudo password once, on its own row. Nothing is written until every box has answered.

Build — and what is in the way, first

The servers picked, the summary confirmed. Before a line is written, every box and every filing is checked for what would get in the way — a set filed under the same name, a box that already carries a mongod with data or another cluster's router, keyfiles left from before — and shown as one list with the fix beside each line: Clean the ticked and check again, or Stop — nothing touched. Then the build starts on every box at once; a box that still fails is named with what it found, and the build ends with every wire proved.

Grow it to nineteen servers, shard the collections, update the OS

Two more shards and two more config servers dropped in; Apply puts them in place and the sets already there are left as they run. Then a collection sharded on a key, with per-shard bars and the balancer's verdict. Then the Linux updates of the whole cluster walked from a router — config set, shards rolling, routers one at a time, MongoDB's own packages held out — while the apps keep writing. Where it ended: five config servers, four shards, two routers.

The cluster backed up as one thing, and put back whole

A shard holds one slice of every sharded collection, so a dump of one piece is meaningless alone. Vigia pauses the balancer through a router, dumps the config set and every shard with the oplog at the same moment — each on a secondary of its own — into one folder with a manifest beside every piece, and puts the balancer back the moment it ends. On a schedule, the same thing goes to a repository: here, Cloudflare R2. The log of every box, or of every box in one role, is one window.

Then the test that matters: the database dropped, brought back from R2 through a router, its collections sharded again on the keys the manifest kept, every shard's slice loaded from the box that holds it. Restored under a different name, too. And "shard as before" replicates the original's sharding onto the copy, with the collections you leave out left out.

/ THE CLUSTER, READ

Themis reads the cluster.

With the cluster built, Themis reads it through the probes and lists what to change — each recommendation a row with Run, Show me and No. Nothing changes until you press Run; the exact script is a click away.

Beside it, where the test fleet ended: five config servers, four shards, two routers — nineteen boxes across Rocky, Alma, Debian and Ubuntu, every wire proved.

Everything above is in the free tier

Replication, sharding, TLS, cluster backups: every Vigia server gets all of it. What is licensed is the server, not the feature.

Download Vigia