Navigation
This is an upcoming (i.e. in progress) version of the manual.
  • Transactions >
  • Production Considerations (Sharded Clusters)

Production Considerations (Sharded Clusters)

Starting in version 4.2, MongoDB provides the ability to perform multi-document transactions for sharded clusters.

Sharded Clusters Transactions (Beta)

To join the beta program for sharded clusters transactions, sign up at Distributed Transactions Beta Sign-Up.

The following page lists concerns specific to running transactions on a sharded cluster. These concerns are in addition to those listed in Production Considerations.

Sharded Transctions and MongoDB Drivers

For transactions on sharded clusters, clients require MongoDB drivers updated for MongoDB 4.2.

Sharded Transactions and MongoDB 4.0 drivers

On sharded clusters with multiple mongos instances, performing transactions with drivers updated for MongoDB 4.0 (instead of MongoDB 4.2) will fail and can result in errors, including:

Note

Your driver may return a different error. Refer to your driver’s documentation for details.

Error Code Error Message
251 cannot continue txnId -1 for session ... with txnId 1
50940 cannot commit with no participants

Performance

Single Shard

Transactions that target a single shard should have the same performance as replica-set transactions.

Multiple Shards

Transactions that affect multiple shards incur a greater performance cost.

Note

On a sharded cluster, transactions that span multiple shards will error and abort if any involved shard contains an arbiter.

Time Limit

To specify a time limit, specify a maxTimeMS limit on commitTransaction. If maxTimeMS is unspecified, MongoDB will use the transactionLifetimeLimitSeconds.

If maxTimeMS is specified but would result in transaction that exceeds transactionLifetimeLimitSeconds, MongoDB will use the transactionLifetimeLimitSeconds.

Read Concerns

Multi-document transactions support "local", "majority", and "snapshot" read concern levels.

For transactions on a sharded cluster, only the "snapshot" read concern provides a consistent snapshot across multiple shards.

For more information on read concern and transactions, see Transactions and Read Concern.

Shard Configuration Restriction

You cannot run transactions on a sharded cluster that has a shard with writeConcernMajorityJournalDefault set to false.

Arbiters

On a sharded cluster, transactions that span multiple shards will error and abort if any involved shard contains an arbiter.

Three Member Primary-Secondary-Arbiter Shards

For a sharded cluster with a three-member PSA shards, you may have disabled read concern “majority” to avoid cache pressure.

For a sharded cluster that has disabled read concern "majority":

  • A transaction with read concern snapshot errors if the transaction involves a shard with read concern "majority" disabled.
  • A transaction that spans multiple shards errors if the transaction involves a shard with read concern "majority" disabled.

To check if read concern “majority” is disabled (--enableMajorityReadConcern false or replication.enableMajorityReadConcern: false), you can run db.serverStatus() and check the storageEngine.supportsCommittedReads field. If false, read concern “majority” is disabled.

Backups and Restores

Warning

To maintain the atomicity guarantees of transactions across shards, use the coordinated backup and restore services provided by MongoDB Atlas or MongoDB Ops Manager. Manual backups and restores do not maintain the atomicity guarantees of transactions across shards.

Chunk Migrations

Chunk migration acquires exclusive collection locks during certain stages.

If an ongoing transaction has a lock on a collection and a chunk migration that involves that collection starts, these migration stages must wait for the transaction to release the locks on the collection, thereby impacting the performance of chunk migrations.

If a chunk migration interleaves with a transaction (for instance, if a transaction starts while a chunk migration is already in progress and the migration completes before the transaction takes a lock on the collection), the transaction errors during the commit and aborts.

Depending on how the two operations interleave, some sample errors include (the error messages have been abbreviated):

  • an error from cluster data placement change ... migration commit in progress for <namespace>
  • Cannot find shardId the chunk belonged to at cluster time ...

Additional Information

See also Production Considerations.