MongoDB Replication

Parent: MongoDB Expert Knowledge · Published reference · snapshot 2026-09-08 · skill mongodb-expert/references/mongodb-replication.md

↓ Facts as markdown all context files

MongoDB replication provides redundancy and high availability through replica sets -- groups of mongod processes that maintain the same data set. A replica set contains one primary member that receive

These notes link each claim to its source. Some citations identify archived research reports that are no longer hosted on this site. A published reference means the content is available; it does not certify independent review or accuracy.Read the editorial policy and follow the sources before relying on a claim.

Overview

MongoDB replication provides redundancy and high availability through replica sets -- groups of mongod processes that maintain the same data set. A replica set contains one primary member that receives all writes and one or more secondary members that replicate the primary's data asynchronously via the oplog (operations log). Replica sets are the foundation of MongoDB's data durability, fault tolerance, and read scaling strategy. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-replication/#overview]
Key guarantees of a properly configured replica set: [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-replication/#overview]
- Automatic failover: if the primary becomes unavailable, an election promotes a secondary to primary within ~12 seconds (median, with default settings). [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-replication/#overview]
- Data redundancy: every data-bearing member holds a complete copy of the data set. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-replication/#overview]
- Read scaling: applications can distribute reads across secondaries using read preferences. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-replication/#overview]
- Tunable consistency: write concern and read concern let applications choose their durability and consistency guarantees per operation. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-replication/#overview]

1.1 Member Types

Primary: The only member that accepts write operations. Records all writes to its oplog. At most one primary per replica set at any time. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-replication/#11-member-types]
Secondary: Maintains an identical copy of the primary's data set by asynchronously applying operations from the primary's oplog. Can serve read operations when read preference allows it. Can be elected primary during failover. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-replication/#11-member-types]
Arbiter: Participates in elections but holds no data. Provides a tiebreaking vote in even-member-count topologies. Must not run on the same system as primary or secondary members. Has exactly 1 election vote and a default priority of 0. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-replication/#11-member-types]
Hidden Members: Must have priority: 0, so they cannot become primary. Excluded from default client read routing. Use for dedicated tasks: reporting queries, backups, analytics workloads. Only reachable by direct connection. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-replication/#11-member-types]
Delayed Members: Maintain a time-delayed copy of the data (configured via secondaryDelaySecs). Must be hidden and should be non-voting. Serve as a defense against accidental data destruction -- the delayed copy preserves the state from N seconds ago. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-replication/#11-member-types]

1.3 Recommended Topologies

Three-member replica set (P-S-S): One primary, two secondaries. Minimum recommended production topology. Tolerates one member failure while maintaining majority for elections and w: "majority" writes. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-replication/#13-recommended-topologies]
Primary-Secondary-Arbiter (P-S-A): Costs less but carries availability risk. If the sole data-bearing secondary goes down, w: "majority" writes fail. Avoid in sharded clusters. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-replication/#13-recommended-topologies]
Geographically distributed: Place members across data centers. Ensure majority of voting members resides in the primary data center. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-replication/#13-recommended-topologies]

2.1 Election Triggers

Elections occur when: a new node is added; the set is initiated with rs.initiate(); maintenance commands run (rs.stepDown(), rs.reconfig()); secondaries lose connectivity to primary for longer than electionTimeoutMillis (default 10s); or the primary detects it can see only a minority of voting members. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-replication/#21-election-triggers]

2.2 Election Protocol (pv1)

MongoDB uses Raft-based consensus (pv1): heartbeats every 2 seconds; if no heartbeat within 10s member is marked inaccessible; candidate runs dry election first; first member to receive majority of votes becomes primary. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-replication/#22-election-protocol-pv1]

2.3 Priority and Votes

Higher-priority members call elections sooner. priority: 0 members cannot become primary. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-replication/#23-priority-and-votes]
Maximum 7 voting members, up to 50 total members. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-replication/#23-priority-and-votes]
Non-voting members must have priority: 0 and votes: 0. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-replication/#23-priority-and-votes]

3.1 What Is the Oplog

The oplog (local.oplog.rs) is a capped collection recording all write operations in idempotent format. Every member maintains its own oplog. Secondaries copy and apply entries from the primary's oplog. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-replication/#31-what-is-the-oplog]

3.3 Oplog Window

The oplog window is the time between the newest and oldest oplog entry. A secondary that falls behind more than the oplog window must perform a full initial sync. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-replication/#33-oplog-window]

4. Write Concern

Write concern controls durability before the server acknowledges a write. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-replication/#4-write-concern]

4.3 `j` (Journal) Option

j: true: synced to on-disk journal before ack. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-replication/#43-j-journal-option]
j: false: in-memory ack only. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-replication/#43-j-journal-option]
With w: "majority", controlled by writeConcernMajorityJournalDefault (default true). [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-replication/#43-j-journal-option]

4.4 `wtimeout`

Time limit (ms) for propagation. Does not undo applied writes on timeout. 0 = wait indefinitely. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-replication/#44-wtimeout]

4.5 Default Write Concern

MongoDB 5.0+: { w: "majority" } for most deployments. Exception: P-S-A topologies default to { w: 1 }. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-replication/#45-default-write-concern]

4.7 Write Concern and Transactions

Set at transaction level, not per-operation: [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-replication/#47-write-concern-and-transactions]

5. Read Preference

maxStalenessSeconds (min 90s) excludes secondaries lagging beyond threshold. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-replication/#5-read-preference]

6.4 Causal Consistency (summary)

Use rc: "majority" + wc: "majority" for causal consistency. MongoDB sets afterClusterTime automatically in causally consistent sessions. See §17 for full coverage. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-replication/#64-causal-consistency-summary]

7.1 When Rollbacks Occur

A rollback reverts writes on a former primary when it rejoins after failover, when those writes had not replicated to a majority before the primary stepped down. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-replication/#71-when-rollbacks-occur]

7.2 Rollback Algorithms

Recover-to-a-timestamp (default, MongoDB 4.0+): reverts to consistent point, re-applies ops. No size limit. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-replication/#72-rollback-algorithms]
Rollback via refetch (legacy, only when enableMajorityReadConcern=false, fixed to true in 5.0+): limited to 300 MB. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-replication/#72-rollback-algorithms]

7.4 Preventing Rollbacks

Use { w: "majority" }. Enable journaling. Monitor replication lag. Avoid P-S-A topologies. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-replication/#74-preventing-rollbacks]

8. Replication Lag Diagnosis

Common causes: slow disk I/O, secondary read overload, index builds, network congestion, large bulk writes, long transactions. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-replication/#8-replication-lag-diagnosis]
Flow control: limits primary write rate to keep majority-committed lag under flowControlTargetLagSeconds (default 10s). [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-replication/#8-replication-lag-diagnosis]

9. Initial Sync

Steps: database cloning → index building → oplog buffering → oplog application → SECONDARY state. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-replication/#9-initial-sync]
Ensure oplog window covers sync duration. Up to 10 retry attempts; 24h transient error window. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-replication/#9-initial-sync]

10. Change Streams Over Replica Sets

Every change event has a resume token (_id). Use resumeAfter to resume from a token; startAfter to resume even after invalidate events. Tokens expire when oplog entry is truncated. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-replication/#10-change-streams-over-replica-sets]
MongoDB 6.0+: fullDocumentBeforeChange and fullDocument: 'updateLookup' for pre/post images (requires changeStreamPreAndPostImages on collection). [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-replication/#10-change-streams-over-replica-sets]

11. Replica Set Maintenance

Rolling maintenance: maintain secondaries first, then rs.stepDown() and maintain former primary. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-replication/#11-replica-set-maintenance]

13. Troubleshooting Checklist

Election not completing: verify majority reachable (rs.status()), check electionTimeoutMillis, check for network partition. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-replication/#13-troubleshooting-checklist]
Replication lag: rs.printSecondaryReplicationInfo(), check disk I/O, index builds (db.currentOp()), flow control (serverStatus.flowControl). [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-replication/#13-troubleshooting-checklist]
Rollback occurred: inspect <dbpath>/rollback/, check write concern used, bsondump rolled-back BSON. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-replication/#13-troubleshooting-checklist]
Initial sync failing: verify oplog window size, disk space, sync source state, network connectivity. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-replication/#13-troubleshooting-checklist]

15. Cross-References

mongodb-expert: General MongoDB architecture and operations. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-replication/#15-cross-references]
mongodb-atlas-expert: Atlas-managed replica sets and Atlas-specific settings. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-replication/#15-cross-references]
mongodb-data-lifecycle: Change streams deep coverage, CDC architectures, pre/post images. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-replication/#15-cross-references]
mongodb-sharding: Sharded cluster replication, config server replica sets, chunk migration. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-replication/#15-cross-references]
mongodb-performance-troubleshooting: Replication lag analysis, slow oplog application. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-replication/#15-cross-references]
mongosync: Inter-cluster replication - Atlas Live Migration, C2C Sync, active-passive DR. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-replication/#15-cross-references]

16.1 Read Concern Levels Comparison

"local": Returns the most recent data on the targeted node with no majority confirmation. On a secondary, data may not yet be replicated to a majority of members and could be rolled back if the current primary fails before replication completes. This is the default for find, aggregate, and getMore operations. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-replication/#161-read-concern-levels-comparison]
"available": Identical to "local" on replica set members. On sharded clusters it diverges: reads are served directly from the shard that owns the chunk without consulting config servers for up-to-date routing metadata. During chunk migrations this can return orphaned documents. Avoid on sharded collections for any consistency-sensitive reads. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-replication/#161-read-concern-levels-comparison]
"majority": Returns only data acknowledged by a majority of data-bearing voting members and written to the majority-committed oplog point. Guaranteed durable; will never be rolled back. Requires WiredTiger (only storage engine since MongoDB 5.0). [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-replication/#161-read-concern-levels-comparison]
"linearizable": Strongest single-document consistency guarantee. Reads block until the server confirms no write started before the read is still in-flight at a majority. Always targets the primary. Must be combined with maxTimeMS. Cannot be used with $out, $merge, or multi-document transactions. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-replication/#161-read-concern-levels-comparison]
"snapshot": Returns data from a consistent snapshot of majority-committed data at a single point in time. Primarily used in multi-document transactions. When a transaction commits with w: "majority", the snapshot guarantee is preserved end-to-end. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-replication/#161-read-concern-levels-comparison]

16.2 Majority Read Concern Mechanics

MongoDB maintains an internal majority-committed optime - the oplog timestamp up to which a majority of data-bearing voting members have confirmed replication. The primary advances this by computing the highest optime for which floor(votingMembers/2)+1 members have reported an optime >= that value, every heartbeat cycle (~2s). [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-replication/#162-majority-read-concern-mechanics]
WiredTiger maintains an in-memory read snapshot pegged to the majority-committed optime. "majority" reads access this snapshot directly - they do not block writes and add negligible latency in steady state. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-replication/#162-majority-read-concern-mechanics]
The interaction with w: "majority" write concern is tight: a write acknowledged at w: "majority" has by definition advanced the majority-commit point to at least its optime. A subsequent read with read concern "majority" (rc: "majority") on any node will therefore see that write - this is the foundation of the causal consistency guarantee. (rc: is used as shorthand for "read concern level" throughout §16–17.) [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-replication/#162-majority-read-concern-mechanics]

16.3 Linearizable vs Snapshot — When to Choose Each

Choose "linearizable" when: [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-replication/#163-linearizable-vs-snapshot-when-to-choose-each]
- You need the absolute freshest majority-committed data for a single document. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-replication/#163-linearizable-vs-snapshot-when-to-choose-each]
- You are building a compare-and-swap or test-and-set operation. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-replication/#163-linearizable-vs-snapshot-when-to-choose-each]
- Always pair with maxTimeMS to bound the blocking window. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-replication/#163-linearizable-vs-snapshot-when-to-choose-each]
Choose "snapshot" when: [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-replication/#163-linearizable-vs-snapshot-when-to-choose-each]
- You need a consistent view across multiple documents or collections within a transaction. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-replication/#163-linearizable-vs-snapshot-when-to-choose-each]
- You want point-in-time consistency without the primary-only restriction of "linearizable". [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-replication/#163-linearizable-vs-snapshot-when-to-choose-each]
Key difference: "linearizable" waits for in-flight writes before responding (most current possible). "snapshot" reads from a fixed point in time and does not wait. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-replication/#163-linearizable-vs-snapshot-when-to-choose-each]

16.4 Read Concern in Sharding — `"available"` vs `"local"` Divergence

For sharded clusters, default to "local" or "majority". "available" exists primarily as a performance optimization for non-sharded workloads. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-replication/#164-read-concern-in-sharding-available-vs-local-divergence]

16.6 Code Examples — Setting Read Concern

Node.js (MongoDB Driver 6.x): [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-replication/#166-code-examples-setting-read-concern]
Python (PyMongo 4.x): [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-replication/#166-code-examples-setting-read-concern]
Java (MongoDB Driver 5.x): [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-replication/#166-code-examples-setting-read-concern]

17.1 What Causal Consistency Means

Causal consistency guarantees that operations within a session (or across sessions sharing causal tokens) observe a logically consistent sequence of writes: [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-replication/#171-what-causal-consistency-means]
MongoDB implements causal consistency through two logical clocks in every server response: [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-replication/#171-what-causal-consistency-means]
- $clusterTime: A hybrid logical clock (HLC) providing total ordering across the replica set. Every server response includes the current $clusterTime. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-replication/#171-what-causal-consistency-means]
- operationTime: The optime of the most recent operation in the session. Clients send it as afterClusterTime on the next read. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-replication/#171-what-causal-consistency-means]
When a read is issued with afterClusterTime: T, the server waits until its majority-committed optime >= T before executing, ensuring the read sees all writes up to time T. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-replication/#171-what-causal-consistency-means]

17.2 Session Setup and Lifecycle

Node.js driver session API: [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-replication/#172-session-setup-and-lifecycle]
Key session methods: [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-replication/#172-session-setup-and-lifecycle]
- session.advanceClusterTime(clusterTime) - advance session cluster time (for cross-service token passing). [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-replication/#172-session-setup-and-lifecycle]
- session.advanceOperationTime(operationTime) - advance operation time (same purpose). [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-replication/#172-session-setup-and-lifecycle]
- session.endSession() - always call in a finally block. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-replication/#172-session-setup-and-lifecycle]

17.3 Why Read Concern `"majority"` Is Required for Causal Consistency

With "local" read concern, afterClusterTime still runs but data returned may include not-yet-majority-committed writes that could be rolled back, breaking the causal chain. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-replication/#173-why-read-concern-majority-is-required-for-causal-consistency]
With "majority", data is from the permanent majority-committed snapshot. The causal chain holds because both write (w: "majority") and read (rc: "majority") anchor to the same majority-commit point. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-replication/#173-why-read-concern-majority-is-required-for-causal-consistency]
"linearizable" also satisfies causal consistency but adds primary-only and in-flight-write-wait constraints - overkill for most causal use cases. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-replication/#173-why-read-concern-majority-is-required-for-causal-consistency]

17.4 Causal Consistency Across Multiple Clients

When this pattern is essential: writing via one API service then reading via another; sequential user actions where step 2 must see step 1; reading your own writes from a secondary. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-replication/#174-causal-consistency-across-multiple-clients]

17.6 Implicit vs Explicit Sessions

Every MongoDB operation uses a session, even if you do not create one explicitly. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-replication/#176-implicit-vs-explicit-sessions]
Key implications: [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-replication/#176-implicit-vs-explicit-sessions]
- Implicit sessions provide no causal ordering guarantees between operations. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-replication/#176-implicit-vs-explicit-sessions]
- Explicit sessions maintain clusterTime and operationTime across all operations. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-replication/#176-implicit-vs-explicit-sessions]
- Multi-document transactions always require an explicit session. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-replication/#176-implicit-vs-explicit-sessions]
- Explicit sessions are lightweight - negligible cost for the duration of a request-response cycle. Exception: sessions with an active transaction hold a WiredTiger snapshot and should be kept short to avoid cache pressure (see §17.7). Always call endSession(). [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-replication/#176-implicit-vs-explicit-sessions]
- Implicit sessions are fine for fire-and-forget writes where read-your-writes is not required. [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-replication/#176-implicit-vs-explicit-sessions]

17.7 Common Pitfalls

(rc: = read concern level shorthand used below.) [archived source: https://llms-explorer.com/sources/mdb-context-hub/mongodb-replication/#177-common-pitfalls]

Where this helps

Designing a production replica-set topology and needing to choose between a three-member P-S-S set and a cheaper but riskier Primary-Secondary-Arbiter configuration. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
Diagnosing replication lag or a failed election during an incident, using the right diagnostic commands (rs.status(), rs.printSecondaryReplicationInfo(), flowControl stats) for the actual failure mode. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
Choosing the right read/write concern combination for a specific consistency requirement — causal consistency, linearizable single-document reads, or transactional snapshot isolation. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
Building a cross-service workflow where one service writes and another reads and must see that write, requiring an explicit understanding of causal consistency and session tokens. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.

Project ideas

Build a replication-lag dashboard that surfaces rs.printSecondaryReplicationInfo() output alongside flow-control status, distinguishing disk I/O lag from index-build lag from network congestion. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
Implement causally consistent reads across two backend services by passing clusterTime and operationTime tokens between them via an explicit session, so a read in service B reliably observes a write from service A. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
Build a delayed-member disaster-recovery setup using secondaryDelaySecs as a defense against accidental mass deletion or corruption, with a runbook for promoting the delayed copy. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
Write a rollback-file inspector that uses bsondump against a former primary's rollback directory to recover writes that didn't replicate before a failover. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.

Antipatterns

Running a Primary-Secondary-Arbiter (P-S-A) topology in production, where w: "majority" writes fail entirely if the sole data-bearing secondary goes down — and it's explicitly discouraged in sharded clusters. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
Using "local" read concern when the application actually needs causal consistency, since data returned under "local" can include writes that haven't been majority-committed and could still be rolled back. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
Reaching for "linearizable" read concern by default instead of "majority" or "snapshot", when linearizable's primary-only, in-flight-write-wait behavior is overkill for most causal-consistency use cases. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
Letting a secondary fall behind further than the oplog window during maintenance, forcing a full initial sync instead of a quick catch-up once it reconnects. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.

Known issues

Elections triggered by a lost heartbeat take roughly 10 seconds by default before a candidate even starts, so a hard failover has an unavoidable window where the replica set has no primary. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
The two rollback algorithms behave very differently: the legacy "rollback via refetch" path is capped at 300MB, while the default "recover to a timestamp" approach (4.0+) has no fixed size limit, but only with majority read concern, forced on since 5.0. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
Change stream resume tokens expire once the underlying oplog entry they reference gets truncated, so a consumer offline longer than the oplog window can't simply resume — it needs a fresh starting point. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
Explicit sessions with an active transaction hold a WiredTiger snapshot for their duration, so keeping a transactional session open too long adds real cache pressure, unlike implicit or non-transactional sessions. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.

Children

← the whole tree · 3D view· how to read this page