MongoDB

Versions

Version	Status	Notes
8	Available	Recommended
7	Available
6	Available

Connecting

Parameter	Value
Host	{name}.db.foundrydb.com
Port	27017
Default database	defaultdb
TLS	Required

mongosh "mongodb://USER:PASS@HOST:27017/defaultdb?tls=true"

Full connection string examples: Connection Strings →

Replica Sets

All MongoDB services run as a 3-member replica set by default, providing:

• Automatic failover if the primary goes down
• Read preference routing (secondaryPreferred, nearest)
• Oplog-based point-in-time recovery

MongoDB replica set, oplog replication and failover

Steady state · write to PRIMARY · oplog replicates to secondaries

Clientrs0write →Primary:27017⇢ oplogSecondary:27017Secondary:27017

write (to primary)primarysecondaryoplog replicationheartbeat (dashed)unreachable / election

How the replica set works

A replica set is a group of mongod members that hold the same data set. At any moment exactly one member is the primary and the rest are secondaries.

• Primary. The single member that accepts writes. Every write is applied to the primary's data and recorded as an entry in its oplog (operations log), a special capped collection (local.oplog.rs) that holds an idempotent description of each change.
• Secondaries. Each secondary continuously tails the primary's oplog and replays those operations against its own copy, so it converges on the same state. Secondaries can serve reads when the client opts in with a read preference.
• Heartbeats. Members ping each other on a regular interval. These heartbeats are how the set detects that a member has become unreachable.

Elections and automatic failover

When the primary stops responding, its peers notice the missed heartbeats and the surviving members hold an election. Each eligible member can vote, and a majority of votes is required to elect a new primary, which is why a set needs an odd number of voting members (three by default) to keep a clear majority. The member with the most up-to-date oplog that can gather a majority becomes the new primary, and your driver, having been given the replica set name, discovers the new topology and re-routes writes automatically. (See the Failover section for manual and automatic failover behaviour.)

Read preference

By default reads go to the primary, giving you the most recent data. You can direct reads to secondaries to spread read load or to read from a topologically nearer member, at the cost of possibly reading slightly stale data because a secondary may lag a little behind the primary:

Read preference	Reads served by
primary (default)	Primary only
primaryPreferred	Primary, or a secondary if no primary is available
secondary	Secondaries only
secondaryPreferred	Secondaries, or the primary if no secondary is available
nearest	The member with the lowest network latency

mongodb://USER:PASS@HOST:27017/defaultdb?tls=true&replicaSet=rs0&readPreference=secondaryPreferred

Write concern

Write concern controls how many members must acknowledge a write before it is reported as successful. w:majority waits for a majority of voting members, which means an acknowledged write survives the failure of any single member, because a future election can only choose a member that already has the write. Lowering the write concern (for example w:1) returns faster but reduces that durability guarantee.

mongodb://USER:PASS@HOST:27017/defaultdb?tls=true&replicaSet=rs0&w=majority

The replica set name is returned in the service detail response:

curl -u admin:password https://api.foundrydb.com/managed-services/{id} \
  | jq '.replica_set_name'

Use it in your connection string for proper topology awareness:

mongodb://USER:PASS@HOST:27017/defaultdb?tls=true&replicaSet=rs0

Add Nodes

Scale to a 5-member replica set for higher read throughput:

curl -u admin:password -X POST \
  https://api.foundrydb.com/managed-services/{id}/nodes \
  -H "Content-Type: application/json" \
  -d '{"role": "replica"}'

Failover

Manual failover to a specific secondary:

curl -u admin:password -X POST \
  https://api.foundrydb.com/managed-services/{id}/nodes/{node_id}/failover

Automatic failover happens within ~10 seconds if the primary becomes unreachable:

1. The surviving members hold a native replica-set election and vote a new primary among themselves. The platform triggers and observes the election rather than hand-picking the winner, then reconciles its own topology to match whichever member won.
2. The stable endpoint follows the newly elected primary, so writes keep landing on the current primary. Your driver also reconnects on its own.
3. The lost member is replaced automatically: a fresh VM is provisioned, added to the set, and brought up to date by MongoDB's native initial sync until it reaches SECONDARY. This restores both data redundancy and the voting-member count, so the cluster self-heals back to its full size instead of running with a thinner quorum.
4. If the old primary later comes back online, it rejoins as a SECONDARY and catches up through the oplog (rolling back any writes that never reached the elected primary), rather than being discarded.

Failover and member replacement are automatic. The case that needs a human is losing the primary without a voting majority left to elect a replacement (for example a single-node service), where the set cannot form a quorum to fail over.

Point-in-Time Recovery

Point-in-time recovery is built on the same oplog that drives replication. Because the oplog records an ordered, idempotent entry for every write, archiving those entries continuously lets a restore replay history up to an exact instant. A PITR restore starts from a base backup snapshot and then replays archived oplog entries forward, stopping at the timestamp you request, so you recover the data set as it existed at that moment. The achievable recovery window depends on how far back the archived oplog reaches.

Continuous oplog archiving. Restore to any timestamp:

curl -u admin:password -X POST \
  https://api.foundrydb.com/managed-services/{id}/backups/restore \
  -H "Content-Type: application/json" \
  -d '{
    "restore_point": "2026-03-15T14:30:00Z",
    "target_service_name": "my-mongo-restored"
  }'

Configuration

curl -u admin:password -X PATCH \
  https://api.foundrydb.com/managed-services/{id}/configuration \
  -H "Content-Type: application/json" \
  -d '{
    "parameters": {
      "operationProfiling.slowOpThresholdMs": "100",
      "operationProfiling.mode": "slowOp"
    }
  }'

Common parameters:

Parameter	Default	Description
operationProfiling.mode	off	Profiling: off, slowOp, all
operationProfiling.slowOpThresholdMs	100	Slow op threshold in ms
net.maxIncomingConnections	65536	Max connections

Indexes

Create indexes via the shell or driver to improve query performance:

// Compound index
db.orders.createIndex({ userId: 1, createdAt: -1 });

// Text search index
db.articles.createIndex({ title: 'text', body: 'text' });

// TTL index (auto-expire documents)
db.sessions.createIndex({ createdAt: 1 }, { expireAfterSeconds: 3600 });

Metrics

curl -u admin:password \
  "https://api.foundrydb.com/managed-services/{id}/metrics?metric=connections&period=1h"

Key metrics: connections, opcounters, replication_lag, wiredtiger_cache_used.

Backups

# List backups
curl -u admin:password https://api.foundrydb.com/managed-services/{id}/backups

# Manual backup
curl -u admin:password -X POST \
  https://api.foundrydb.com/managed-services/{id}/backups \
  -H "Content-Type: application/json" \
  -d '{"backup_type": "manual"}'