Navigation
This version of the documentation is archived and no longer supported.
  • 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.

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 Transactions and MongoDB Drivers

For transactions on MongoDB 4.2 deployments (replica sets and sharded clusters), clients must use MongoDB drivers updated for MongoDB 4.2.

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.

To modify transactionLifetimeLimitSeconds for a sharded cluster, the parameter must be modified for all shard replica set members.

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.

Write Concerns

You cannot run transactions on a sharded cluster that has a shard with writeConcernMajorityJournalDefault set to false (such as a shard with a voting member that uses the in-memory storage engine).

Note

Regardless of the write concern specified for the transaction, the commit operation for a sharded cluster transaction includes some parts that use {w: "majority", j: true} write concern.

Arbiters

Transactions whose write operations span multiple shards will error and abort if any transaction operation reads from or writes to a shard that contains an arbiter.

See also Three Member Primary-Secondary-Arbiter Shards for transaction restrictions on shards that have disabled read concern majority.

Three Member Primary-Secondary-Arbiter Shards

For a sharded cluster with three-member PSA shards, you may have disabled read concern “majority” (i.e. --enableMajorityReadConcern false or replication.enableMajorityReadConcern: false) to avoid cache pressure.

On sharded clusters,
  • If a transaction involves a shard that has disabled read concern “majority”, you cannot use read concern "snapshot" for the transaction. You can only use read concern "local" or "majority" for the transaction. If you use read concern "snapshot", the transaction errors and aborts.

    readConcern level 'snapshot' is not supported in sharded clusters when enableMajorityReadConcern=false.
    
  • Transactions whose write operations span multiple shards will error and abort if any of the transaction’s read or write operations involves a shard that has disabled read concern "majority".

To check if read concern “majority” is disabled,
You can run db.serverStatus() and check the storageEngine.supportsCommittedReads field. If false, read concern “majority” is disabled.

Backups and Restores

Warning

mongodump and mongorestore cannot be part of a backup strategy for 4.2+ sharded clusters that have sharded transactions in progress, as backups created with mongodump do not maintain the atomicity guarantees of transactions across shards.

For 4.2+ sharded clusters with in-progress sharded transactions, use one of the following coordinated backup and restore processes which do 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 ...

Outside Reads During Commit

During the commit for a transaction, outside read operations may try to read the same documents that will be modified by the transaction. If the transaction writes to multiple shards, then during the commit attempt across the shards

  • Outside reads that use read concern snapshot or "linearizable", or are part of causally consistent sessions (i.e. include afterClusterTime) wait for all writes of a transaction to be visible.
  • Outside reads using other read concerns do not wait for all writes of a transaction to be visible but instead read the before-transaction version of the documents available.

Interaction with Replicated Index Builds

For replicated index builds on a collection (as opposed to a rolling index build), once an index build issued against the primary replica set member completes, the secondary members apply the associated oplog entry and start the index build. While building the index, the secondary waits to apply any later oplog entries, including a distributed transaction that commits during the build. If replication stalls for longer than the oplog window, the secondary falls out of sync and requires resynchronization to recover.

To minimize potential interactions between sharded transactions and indexes, consider one of the following strategies for building indexes on sharded clusters:

  • Build indexes during a maintenance window in which applications cease issuing distributed transactions against the collections being indexed.
  • Build indexes using a rolling index build procedure as described in Build Indexes on Sharded Clusters.
  • Increase the oplog size on each replica set member to mitigate the likelihood of falling out of sync due to replicated index builds.

Additional Information

See also Production Considerations.