Causal Consistency

Parent: MongoDB Replication · 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]

Project ideas

Build a "read-your-own-writes" API layer using explicit sessions plus { readConcern: "majority" } so a user sees their own just-submitted update on the very next read, even across load-balanced app servers. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
Design a cross-service causal chain: service A writes with w:"majority" and passes the session's operationTime to service B via a message-queue header; service B reads with afterClusterTime set from that token. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
Build a replication-lag dashboard using rs.printSecondaryReplicationInfo() plus flowControl metrics to alert before secondaries fall outside the oplog window. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
Benchmark P-S-S vs P-S-A topologies under a simulated primary failure to quantify the data-loss-window difference in practice. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.

Where this helps

Multi-service workflows where step 2 must never see stale data from before step 1's write completed, across a service boundary. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
Systems needing tunable durability per operation — cheap "local" reads for dashboards, "majority" reads for anything user-facing, "linearizable" only for compare-and-swap-style operations. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
Deployments that must survive a primary failure without silently losing acknowledged writes (drives write-concern and topology choice). [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
Diagnosing "why did my read return an old value" bugs in a replicated system. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.

Common mistakes

Using "local" read concern after a "majority" write and assuming causal consistency holds — it doesn't; "local" can return not-yet-majority-committed data a rollback could later revert. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
Running a P-S-A (Primary-Secondary-Arbiter) topology in production for cost reasons — if the sole data-bearing secondary goes down, majority writes block entirely. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
Creating a new implicit session per operation instead of reusing one explicit session across a causally related sequence — implicit sessions carry no causal ordering guarantee between operations. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
Ignoring oplog window size relative to expected downtime — a member that falls behind the window must fully resync instead of catching up incrementally. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.

Known issues

Elections take about 12 seconds (median) before a new primary is available — writes and majority reads block during that window; design for it rather than treating failover as instantaneous. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
Legacy rollback-via-refetch caps at 300MB of reverted data; the modern recover-to-timestamp algorithm (4.0+) has no such limit, but a rollback still loses any writes that hadn't reached a majority. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
maxStalenessSeconds has a 90-second minimum — a secondary read preference can't be tuned tighter than that for staleness exclusion. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
Sessions with an active transaction are not lightweight the way ordinary sessions are — holding one open carries real server-side resource cost. [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