Production Considerations (Sharded Clusters)

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

The following page lists concerns specific to running transactions on asharded cluster. These concerns are in addition to those listed inProduction Considerations.

Sharded Transctions and MongoDB Drivers

For transactions on MongoDB 4.2 deployments (replica sets and shardedclusters), clients must use MongoDB drivers updated for MongoDB4.2.

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

Note

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

Performance

Single Shard

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

Multiple Shards

Transactions that affect multiple shards incur a greater performancecost.

Note

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

Time Limit

To specify a time limit, specify a maxTimeMS limit oncommitTransaction.

If maxTimeMS is unspecified, MongoDB will use thetransactionLifetimeLimitSeconds.

If maxTimeMS is specified but would result in transaction thatexceeds transactionLifetimeLimitSeconds, MongoDB will usethe transactionLifetimeLimitSeconds.

To modify transactionLifetimeLimitSeconds for a shardedcluster, the parameter must be modified for all shard replica setmembers.

Read Concerns

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

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

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

Shard Configuration Restriction

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

Arbiters

Transactions whose write operations span multiple shards will errorand abort if any transaction operation reads from or writes to ashard that contains an arbiter.

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

Three Member Primary-Secondary-Arbiter Shards

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

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

readConcern level 'snapshot' is not supported in sharded clusters when enableMajorityReadConcern=false.

• Transactions whose write operations span multiple shards willerror and abort if any of the transaction’s read or writeoperations involves a shard that has disabled read concern"majority".

• To check if read concern “majority” is disabled,
• You can run db.serverStatus() and check thestorageEngine.supportsCommittedReads field. Iffalse, read concern “majority” is disabled.

Backups and Restores

Warning

mongodump and mongorestorecannot be part of a backup strategy for 4.2+ sharded clustersthat have sharded transactions in progress as these tools cannotguarantee a atomicity guarantees of data across the shards.

For 4.2+ sharded clusters with in-progress sharded transactions, forcoordinated backup and restore processes that maintain the atomicityguarantees of transactions across shards, see:

• MongoDB Atlas,
• MongoDB Cloud Manager, or
• MongoDB Ops Manager.

Chunk Migrations

Chunk migration acquiresexclusive collection locks during certain stages.

If an ongoing transaction has a lock on a collection and a chunkmigration that involves that collection starts, these migration stagesmust 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 atransaction starts while a chunk migration is already in progress andthe migration completes before the transaction takes a lock on thecollection), the transaction errors during the commit and aborts.

Depending on how the two operations interleave, some sample errorsinclude (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 …

See also

shardingStatistics.countDonorMoveChunkLockTimeout

Outside Reads During Commit

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

• Outside reads that use read concern snapshot or"linearizable", or are part of causally consistentsessions (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 writesof a transaction to be visible but instead read thebefore-transaction version of the documents available.

See also

Transactions and Atomicity

Additional Information

See also Production Considerations.