Replica Set Transactions
Parent: MongoDB Transactions · Published reference · snapshot 2026-10-20 · skill ranked-3a018e98 · viability 3.60 / 5 (research)
↓ Facts as markdownall context files
Source-anchored research for Replica Set Transactions. Run status: COMPLETED.
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.
How it works
- MongoDB Jira issue SERVER-88746 documents a snapshot-isolation violation in replica-set transactions on version 7.0.0 when writes raced with a collection drop or rename; the issue lists 7.0.10 as the fix version. (low confidence) (verified as of 2024-05-06) [source]
- With transaction commit write concern w:1, MongoDB acknowledges after the primary applies the commit, so a failover can roll the transaction back before replication; when the former primary rejoins, it reverts writes that were not replicated to secondaries. (high confidence) [source]
- Transaction-level read concern snapshot or majority guarantees majority-committed reads only when commit uses write concern majority; without majority at commit, those read concerns alone do not provide that guarantee. (high confidence) [source]
Comparisons and alternatives
- MongoDB keeps a replica-set transaction's changes invisible to outside operations until commit; on commit, all changes become visible together rather than as a partial subset. (high confidence) [source]
Facts and statements
- MongoDB’s production manual says standalone deployments do not support transactions and that replica sets support multi-document transactions. (low confidence) [source]
- The current production manual requires every replica-set member to have featureCompatibilityVersion 4.0 or later for transactions. (low confidence) (verified as of 2026-10-20) [source]
- A transaction containing reads must use read preference primary, and all operations in that transaction route to the same replica-set member. (high confidence) [source]
- Within a transaction, readConcern snapshot guarantees a snapshot of majority-committed data only if commitTransaction uses writeConcern majority; without majority at commit, that guarantee does not hold. (high confidence) [source]
- A transaction committed with writeConcern w:1 can be rolled back after failover; writeConcern majority acknowledges after the commit is applied to a majority of voting members. (high confidence) [source]
- A 2022 formal-verification paper models the REPLICASET transaction protocol separately and reports that it satisfies a Strong-SI variant of snapshot isolation under the paper’s formal model. (low confidence) [source]
- Jepsen’s MongoDB 4.2.6 evaluation found snapshot-isolation anomalies, but it tested a two-shard cluster whose config replica set and data shards each had three members, so it does not isolate replica-set-only transactions. (high confidence) [source]
- MongoDB's replication README says durability of a single replica-set transaction is not guaranteed until commitTransaction is majority committed; it also says unprepared transactions in progress are aborted during stepdown and are not recovered on failover. (high confidence) [source]
- A 2022 formal-verification paper models MongoDB's replica-set transaction protocol from documentation and source code and reports that its REPLICASET model satisfies Realtime-SI. (medium confidence) [source]
- MongoDB documents an exception to majority durability: if writeConcernMajorityJournalDefault is false, a transient loss of a majority of replica-set nodes can still allow majority-acknowledged writes to roll back. (high confidence) (verified as of 2026-10-14) [source]
Children
- No children recorded.