On this page本页内容
Starting in version 4.2, MongoDB provides the ability to perform multi-document transactions for sharded clusters.从版本4.2开始，MongoDB提供了为分片集群执行多文档事务的能力。
The following page lists concerns specific to running transactions on a sharded cluster. 以下页面列出了特定于在分片集群上运行事务的关注点。These concerns are in addition to those listed in Production Considerations.这些问题是生产注意事项中列出的问题之外的问题。
For transactions on MongoDB 4.2 deployments (replica sets and sharded clusters), clients must use MongoDB drivers updated for MongoDB 4.2.对于MongoDB 4.2部署（副本集和分片集群）上的事务，客户端必须使用为MongoDB 4.2更新的MongoDB驱动程序。
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:mongos实例的分片集群上，使用为MongoDB 4.0（而不是MongoDB 4.2）更新的驱动程序执行事务将失败，并可能导致错误，包括：
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 |
Transactions that target a single shard should have the same performance as replica-set transactions.以单个分片为目标的事务应具有与副本集事务相同的性能。
Transactions that affect multiple shards incur a greater performance cost.影响多个分片的事务会产生更高的性能成本。
On a sharded cluster, transactions that span multiple shards will error and abort if any involved shard contains an arbiter.在分片集群上，如果任何涉及的分片包含仲裁器，则跨多个分片的事务将出错并中止。
To specify a time limit, specify a 要指定时间限制，请在maxTimeMS limit on commitTransaction.commitTransaction上指定maxTimeMS限制。
If 如果未指定maxTimeMS is unspecified, MongoDB will use the transactionLifetimeLimitSeconds.maxTimeMS，MongoDB将使用transactionLifetimeLimitSeconds。
If 如果指定了maxTimeMS is specified but would result in transaction that exceeds transactionLifetimeLimitSeconds, MongoDB will use the transactionLifetimeLimitSeconds.maxTimeMS，但会导致事务超过transactionLifetimeLimitSeconds，MongoDB将使用transactionLifetimeLimitSeconds。
To modify 要修改分片群集的transactionLifetimeLimitSeconds for a sharded cluster, the parameter must be modified for all shard replica set members.transactionLifetimeLimitSeconds，必须修改所有分片副本集成员的参数。
Multi-document transactions support 多文档事务支持"local", "majority", and "snapshot" read concern levels."local"、"majority"和"snapshot"读取关注级别。
For transactions on a sharded cluster, only the 对于分片集群上的事务，只有"snapshot" read concern provides a consistent snapshot across multiple shards."snapshot"读取问题提供了跨多个分片的一致快照。
For more information on read concern and transactions, see Transactions and Read Concern.有关读取关注点和事务的更多信息，请参阅事务和读取关注点。
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).writeConcernMajorityJournalDefault设置为false的分片集群上运行事务（例如，具有使用内存存储引擎的投票成员的分片）。
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.{w: "majority", j: true}写关注点的部分。
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.如果任何事务操作读取或写入包含仲裁器的分片，则其写入操作跨越多个分片的事务将出错并中止。
mongodump and mongorestorecannot 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.mongodump和mongorestore不能作为4.2+分片化集群的备份策略的一部分，因为使用mongoump创建的备份不能维护分片之间事务的原子性保证。
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:对于具有正在进行的分片事务的4.2以上分片群集，请使用以下协调的备份和恢复过程之一，这些过程可维护跨分片事务的原子性保证：
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 ...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如果事务写入多个分片，则在跨分片提交尝试期间
"snapshot" or "linearizable", or are part of causally consistent sessions (i.e. include afterClusterTime) wait for all writes of a transaction to be visible."snapshot"或"linearizable"的外部读取，或是因果一致会话的一部分（即包含afterClusterTime），等待事务的所有写入可见。See also Production Considerations.另请参见生产注意事项。