Distributed Sharded Transactions
Parent: MongoDB Transactions · Published reference · snapshot 2026-10-20 · skill ranked-3a018e98 · viability 4.25 / 5 (research)
↓ Facts as markdownall context files
Source-anchored research for Distributed Sharded 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
- Percona's historical release notes list a fix for a cross-shard transaction deadlock when FCV was set after a transaction entered prepared state; both the setFCV thread and TransactionCoordinator could hang. (low confidence) [source]
- MongoDB's manuals state that transactions spanning multiple shards incur greater performance cost, abort if an operation touches a shard with an arbiter, and may abort at commit when a chunk migration interleaves with the transaction. (medium confidence) (verified as of 2026-10-14) [source]
Facts and statements
- For cross-shard writes, MongoDB uses a two-phase-commit variant: mongos hands commit to a coordinator shard; participant shards prepare and majority-commit prepare records; after all respond, the coordinator chooses a commit timestamp and sends commit. MongoDB says it can bypass full 2PC for read-only and single-write-shard cases. (high confidence) (verified as of 2026-01-27) [source]
- MongoDB defines transaction outcomes as all changes applying or none, but an outside local read can see one committed shard write before another is visible. Outside reads with snapshot or linearizable read concern, and causally consistent afterClusterTime reads, wait until all transaction writes are visible. (high confidence) (verified as of 2026-10-14) [source]
- For transactions on a sharded cluster, MongoDB documents snapshot as the only transaction read concern that provides a consistent snapshot across multiple shards. (high confidence) (verified as of 2026-10-14) [source]
- MongoDB's manual says multi-shard transactions incur greater performance cost than single-shard transactions. An independent transaction-model comparison attributes cross-shard write slowdown to extra 2PC round trips but provides no quantified benchmark. (medium confidence) (verified as of 2026-10-14) [source]
- A 2022 independent paper formally models MongoDB's SHARDEDCLUSTER protocol from documentation and source code, then concludes that its model satisfies Session-SI, one of the paper's defined snapshot-isolation variants. (low confidence) [source]
- Jepsen's 2020 report tested MongoDB 4.2.6 on a two-shard cluster with a collection sharded by _id and reported read skew, cyclic dependencies, duplicate writes, and internal consistency anomalies, including under the strongest read and write concerns. A May 26, 2020 update says MongoDB attributed anomalies to a transaction-retry bug and planned a patch for 4.2.8; these findings are specific to the tested version and workload. (low confidence) (verified as of 2020-05-26) [source]
- For a sharded-cluster transaction that commits writes on multiple shards, `mongos` routes operations to the affected shards and hands commit coordination to a coordinator shard. The coordinator prepares each participant, waits for affirmative responses, then sends the commit decision to the participants. (high confidence) [source]
- MongoDB can bypass full two-phase commit for read-only transactions and transactions whose writes target only one shard. (high confidence) [source]
- Each participant selects a prepare timestamp and persists its prepared transaction state. After every participant prepares, the coordinator chooses a commit timestamp no earlier than any participant's prepare timestamp and sends that timestamp to all participants, where the writes become visible. (high confidence) [source]
- MongoDB's sharded-cluster manual says only `snapshot` read concern provides a consistent snapshot across multiple shards. During a multi-shard commit, outside reads using `snapshot` or `linearizable`, and causal reads using `afterClusterTime`, wait until all transaction writes are visible; other read concerns can read the before-transaction versions. (high confidence) (verified as of 2026-10-14) [source]
Children
- Coordinator failure recovery (frontier, viability 4.17 / 5)
Frontier under this node: Coordinator failure recovery (4.17)