MongoDB Support: 7 Essential Layers of 24×7 Enterprise Cover

Our MongoDB Support practice exists for that gap, and MongoDB Support from MinervaDB is built to close it permanently rather than incident by incident. We work at the level of the storage engine, the replication protocol and the query planner, and we translate what we find there into changes your teams can ship the same week. The people on the MongoDB Support rota are the people who diagnose the problem; there is no coordinator relaying messages between you and an engineer you never meet.

Vendor neutrality is a principle rather than a slogan. We do not resell MongoDB licences, cloud credits or hardware, so a recommendation to add a shard, move to Atlas, stay self-managed or move a workload off MongoDB entirely is judged on one criterion only: whether it makes your data layer faster, safer or cheaper to run. Our MongoDB consulting and MongoDB optimization practices sit behind the support contract for the project-shaped work.

With default settings a lost primary is detected through missed heartbeats, an election begins once electionTimeoutMillis (10 seconds) expires, the candidate with the highest optime wins a majority vote, and the new primary opens for writes after catch-up. That sequence typically costs ten to twelve seconds of write availability, and MongoDB Support starts by measuring it on your topology. Whether that is acceptable is a business decision, not a database default, and we tune the timeouts against the outage the business can actually absorb, then prove the drivers retry cleanly through it.

The most expensive misunderstanding in MongoDB is the belief that a successful write is a durable write. Acknowledgement means exactly what the write concern says it means and nothing more: a write acknowledged at w:1 that has not reached a majority can be discarded when the old primary rejoins and rolls back, after the application has already told the customer it succeeded. MongoDB Support audits every collection for that exposure and closes it where correctness is not negotiable.

// Engineered replica set: deterministic priority ladder, hidden backup source,
// delayed member for logical corruption, majority floor as the default write concern
cfg = rs.conf()
cfg.members[0].priority = 3            // preferred primary, largest failure domain
cfg.members[1].priority = 2
cfg.members[2].priority = 1
cfg.members[3].priority = 0            // hidden backup source: never elected, never read
cfg.members[3].hidden = true
cfg.members[4].priority = 0            // delayed member: one hour of live rollback capacity
cfg.members[4].hidden = true
cfg.members[4].secondaryDelaySecs = 3600
cfg.settings.electionTimeoutMillis = 5000   // tuned to the written outage budget, not left at 10000
rs.reconfig(cfg)

db.adminCommand({ setDefaultRWConcern: 1,
  defaultWriteConcern: { w: "majority", j: true, wtimeout: 5000 },
  defaultReadConcern:  { level: "majority" } })

// Verify: no member shares a priority, and lag is within the agreed bound
rs.status().members.map(m => ({ name: m.name, state: m.stateStr,
  lagSec: (rs.status().members.find(p => p.stateStr === "PRIMARY").optimeDate - m.optimeDate) / 1000 }))

Field order in compound indexes follows the equality, sort, range guideline. Equality predicates lead, fields that satisfy the sort come next, and range predicates come last. Get the order wrong and MongoDB will still use the index, but it will add a blocking in-memory sort that spills once it exceeds 100 MB, turning a fast query into an unpredictable one. The levers MongoDB Support applies, in order of impact, are: add the missing compound index, reorder an existing one, make the query covered, retire indexes with near-zero usage in $indexStats over a full business cycle, replace leading-wildcard regular expressions with collation-aware or search indexes, and replace large skip values with range-based pagination.

Aggregation is where MongoDB does its most valuable work, where MongoDB Support spends much of its performance time, and where it is easiest to write something that is fast on a test dataset and ruinous in production. A $match that runs first can be served by an index and streams; a $sort without a supporting index and a $group both buffer, capped at 100 MB unless allowDiskUse converts the hard failure into a slow disk-bound success. On a sharded cluster the pipeline is split, and pushing $match and $project before the split is the cheapest optimisation available because it reduces both per-shard work and the bytes that cross the network to the merger.

// 1. Find the query shapes that hurt: profiler at 100 ms, then rank by keysExamined per document returned
db.setProfilingLevel(1, { slowms: 100, sampleRate: 1.0 })
db.system.profile.aggregate([
  { $match: { ns: "shop.orders", op: { $in: ["query", "command"] } } },
  { $group: { _id: "$queryHash", n: { $sum: 1 }, avgMs: { $avg: "$millis" },
              ratio: { $avg: { $divide: ["$keysExamined", { $max: ["$nreturned", 1] }] } } } },
  { $sort: { ratio: -1 } }, { $limit: 10 } ])

// 2. Confirm the plan before and after: no SORT stage, no FETCH on a covered query
db.orders.find({ tenant_id: 42, status: "open", created_at: { $gte: ISODate("2026-09-01") } })
         .sort({ created_at: -1 }).explain("executionStats").executionStats

// 3. Build to E-S-R, rolling, in the agreed window
db.orders.createIndex({ tenant_id: 1, status: 1, created_at: -1 },
  { name: "ix_orders_tenant_status_created" })

// 4. Retire what nothing uses, after a full business cycle of evidence
db.orders.aggregate([{ $indexStats: {} }, { $match: { "accesses.ops": { $lt: 10 } } },
                     { $project: { name: 1, "accesses.ops": 1, "accesses.since": 1 } }])

That is why the oplog window is a first-class recovery metric in our MongoDB Support scorecard rather than a replication detail. If corruption is detected six hours after it happened and the oplog holds four hours, point-in-time recovery is impossible at any price. We size local.oplog.rs against realistic detection and decision time and alert on the trend rather than the breach. Snapshots are taken from a hidden member so production nodes are untouched, sharded clusters are snapshotted consistently across shards rather than one shard at a time, and every restore is timed on production-scale data with the wall-clock result recorded.

The MongoDB Support tooling is chosen per estate: Percona Backup for MongoDB for self-managed replica sets and sharded clusters, Ops Manager or Cloud Manager where Enterprise Advanced is licensed, Atlas continuous backup for managed deployments, or volume snapshots with oplog capture where the platform provides them. The rehearsal is not optional under any of them. The number we insist on knowing is how long a full restore of your largest shard actually takes, on the hardware you have today.

# Oplog window: the metric MongoDB Support trends against your detection time
mongosh --quiet --eval '
  const o = db.getSiblingDB("local").oplog.rs;
  const first = o.find().sort({ $natural: 1 }).limit(1).next().ts.getTime();
  const last  = o.find().sort({ $natural: -1 }).limit(1).next().ts.getTime();
  print("oplog window hours:", ((last - first) / 3600).toFixed(1))'

# Percona Backup for MongoDB: consistent snapshot + continuous oplog, then a timed point-in-time rehearsal
pbm config --set pitr.enabled=true --set pitr.oplogSpanMin=10
pbm backup --type physical --wait
pbm status                                   # snapshot list and PITR ranges: prove the target ts is covered
time pbm restore --time "2026-09-29T20:09:59" --wait   # into the isolated rehearsal replica set
# Verify before any cutover decision: counts, checksums, application smoke tests, then record the wall-clock RTO
mongosh "mongodb://${MDB_USER}:${MDB_PASSWORD}@rehearsal-0,rehearsal-1,rehearsal-2/?replicaSet=rs_rehearsal" \
  --eval 'db.getSiblingDB("shop").orders.countDocuments({ created_at: { $lt: ISODate("2026-09-29T20:10:00Z") } })'

Every MongoDB Support Severity-1 closes with a written root cause analysis and tracked preventive actions, and every action lands in the next monthly service review. The evidence capture below runs before anything is restarted; it takes under a minute and it is the difference between a root cause and a guess. For estates that need the pager held rather than shared, MinervaDB 24×7 emergency DBA coverage and enterprise database management extend the same severity matrix to fully managed operations.

// First-hour evidence capture: run BEFORE any restart, stepdown or index change
const t = new Date().toISOString().replace(/[:.]/g, "-");
const snap = {
  currentOp:    db.adminCommand({ currentOp: true, "secs_running": { $gte: 5 } }),
  serverStatus: db.serverStatus(),
  rsStatus:     rs.status(),
  hostInfo:     db.hostInfo(),
  slowest:      db.getSiblingDB("shop").system.profile.find().sort({ millis: -1 }).limit(50).toArray()
};
fs.writeFileSync(`/var/tmp/mdb-evidence-${t}.json`, JSON.stringify(snap));
// then: contain (kill the runaway op, shed the batch job, add read capacity), diagnose, change, write up