Production Considerations生产考量

Availability可用性

• MongoDB standalone deployments do not support transactions. To use transactions, your deployment must be a multiple node replica set.MongoDB单机版部署不支持事务。要使用事务，部署必须是多节点副本集。
• MongoDB supports multi-document transactions on replica sets.MongoDB支持副本集上的多文档事务。
• Distributed transactions add support for multi-document transactions on sharded clusters and incorporates the existing support for multi-document transactions on replica sets.分布式事务增加了对分片集群上多文档事务的支持，并整合了对副本集上多文档事务的现有支持。

Feature Compatibility功能兼容性

To use transactions, the featureCompatibilityVersion for all members of the deployment must be at least:要使用事务，部署所有成员的featureCompatibilityVersion必须至少为：

To check the FCV for a member, connect to the member and run the following command:要检查成员的FCV，请连接到该成员并运行以下命令：

db.adminCommand( { getParameter: 1, featureCompatibilityVersion: 1 } )

For more information, see the setFeatureCompatibilityVersion reference page.有关更多信息，请参阅setFeatureCompatibilityVersion参考页面。

Runtime Limit运行时间限制

By default, a transaction must have a runtime of less than one minute. You can modify this limit using transactionLifetimeLimitSeconds for the mongod instances. 默认情况下，事务的运行时间必须小于一分钟。您可以使用mongod实例的transactionLifetimeLimitSeconds修改此限制。For sharded clusters, the parameter must be modified for all shard replica set members. Transactions that exceeds this limit are considered expired and will be aborted by a periodic cleanup process.对于分片集群，必须修改所有分片副本集成员的参数。超过此限制的事务将被视为已过期，并将通过定期清理过程中止。

For sharded clusters, you can also specify a maxTimeMS limit on commitTransaction. For more information, see Sharded Clusters Transactions Time Limit.对于分片集群，您还可以在commitTransaction上指定maxTimeMS限制。有关更多信息，请参阅分片群集事务时间限制。

Oplog Size Limit操作日志大小限制

MongoDB creates as many oplog entries as necessary to the encapsulate all write operations in a transaction, instead of a single entry for all write operations in the transaction. This removes the 16MB total size limit for a transaction imposed by the single oplog entry for all its write operations. MongoDB根据需要创建尽可能多的oplog条目，以将所有写入操作封装在事务中，而不是为事务中的所有写入操作创建一个条目。这消除了单个oplog条目对其所有写入操作施加的事务总大小限制16MB。Although the total size limit is removed, each oplog entry still must be within the BSON document size limit of 16MB.虽然删除了总大小限制，但每个oplog条目仍必须在16MB的BSON文档大小限制内。

WiredTiger CacheWiredTiger缓存

To prevent storage cache pressure from negatively impacting the performance:为防止存储缓存压力对性能产生负面影响：

• When you abandon a transaction, abort the transaction.当您放弃事务时，请中止事务。
• When you encounter an error during individual operation in the transaction, abort and retry the transaction.当您在事务的单个操作中遇到错误时，请中止并重试事务。

The transactionLifetimeLimitSeconds also ensures that expired transactions are aborted periodically to relieve storage cache pressure.transactionLifetimeLimitSeconds还可确保定期中止过期的事务，以缓解存储缓存压力。

Transactions and Security事务和安全

• If running with access control, you must have privileges for the operations in the transaction.如果使用访问控制运行，则必须具有事务中操作的权限。
• If running with auditing, operations in an aborted transaction are still audited. However, there is no audit event that indicates that the transaction aborted.如果使用审核运行，则中止事务中的操作仍将被审核。但是，没有审计事件表明事务已中止。

Shard Configuration Restriction分片配置限制

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的分片的分片集群上运行事务（例如具有使用内存存储引擎的投票成员的分片）。

Sharded Clusters and Arbiters分片集群和仲裁者

You cannot change a shard key using a transaction if the replica set has an arbiter. Arbiters cannot participate in the data operations required for multi-shard transactions.如果副本集有仲裁器，则无法使用事务更改分片键。仲裁员不能参与多分片事务所需的数据操作。

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.如果任何事务操作从包含仲裁器的分片读取或写入，则写操作跨越多个分片的事务将出错并中止。

Acquiring Locks获取锁

By default, transactions wait up to 5 milliseconds to acquire locks required by the operations in the transaction. If the transaction cannot acquire its required locks within the 5 milliseconds, the transaction aborts.默认情况下，事务等待最多5毫秒以获取事务中操作所需的锁。如果事务无法在5毫秒内获取所需的锁，则事务中止。

Transactions release all locks upon abort or commit.事务在中止或提交时释放所有锁。

Pending DDL Operations and Transactions待处理的DDL操作和事务

If a multi-document transaction is in progress, new DDL operations that affect the same database(s) or collection(s) wait behind the transaction. While these pending DDL operations exist, new transactions that access the same database(s) or collection(s) as the pending DDL operations cannot obtain the required locks and and will abort after waiting maxTransactionLockRequestTimeoutMillis. 如果正在进行多文档事务，则影响同一数据库或集合的新DDL操作将在事务之后等待。虽然存在这些挂起的DDL操作，但访问与挂起的DDL操作相同的数据库或集合的新事务无法获得所需的锁，并将在等待maxTransactionLockRequestTimeoutMillis后中止。In addition, new non-transaction operations that access the same database(s) or collection(s) will block until they reach their maxTimeMS limit.此外，访问同一数据库或集合的新非事务操作将被阻止，直到它们达到maxTimeMS限制。

Consider the following scenarios:考虑以下情况：

DDL Operation That Requires a Collection Lock需要集合锁的DDL操作

While an in-progress transaction is performing various CRUD operations on the employees collection in the hr database, an administrator issues the db.collection.createIndex() DDL operation against the employees collection. createIndex() requires an exclusive collection lock on the collection.当正在进行的事务对hr（人力资源）数据库中的employees集合执行各种CRUD操作时，管理员会对employees集合发出db.collection.createIndex()DDL操作。createIndex()要求对集合设置独占集合锁。

Until the in-progress transaction completes, the createIndex() operation must wait to obtain the lock. 在进行中的事务完成之前，createIndex()操作必须等待以获取锁。Any new transaction that affects the employees collection and starts while the createIndex() is pending must wait until after createIndex() completes.任何影响employees集合并在createIndex()挂起时启动的新事务都必须等到createIndex()。

The pending createIndex() DDL operation does not affect transactions on other collections in the hr database. 挂起的createIndex()DDL操作不会影响hr数据库中其他集合上的事务。For example, a new transaction on the contractors collection in the hr database can start and complete as normal.例如，hr数据库中contractors（承包商）集合的新事务可以正常启动和完成。

DDL Operation That Requires a Database Lock需要数据库锁的DDL操作

While an in-progress transaction is performing various CRUD operations on the employees collection in the hr database, an administrator issues the renameCollection DDL operation to rename the vendors.contractors collection to hr.contractors. 当一个正在进行的事务正在对hr数据库中的employees集合执行各种CRUD操作时，管理员会发出renameCollection DDL操作，将供应商承包商集合重命名为人力资源承包商。renameCollection requires a database lock on the target database (hr) when it differs from the source database (vendors).当目标数据库（hr）与源数据库（vendors（供应商））不同时，renameCollection要求对其进行数据库锁定。

Until the in-progress transaction completes, the renameCollection operation must wait to obtain the lock. 在进行中的事务完成之前，renameCollection操作必须等待以获取锁。Any new transaction that affects the hr database or any of its collections and starts while the renameCollection is pending must wait until after renameCollection completes.任何影响hr数据库或其任何集合并在renameCollection挂起时启动的新事务都必须等到renameCollection完成。

In either scenario, if the DDL operation remains pending for more than maxTransactionLockRequestTimeoutMillis, pending transactions waiting behind that operation abort. 在任何一种情况下，如果DDL操作保持挂起状态的时间超过maxTransactionLockRequestTimeoutMillis，则等待该操作的挂起事务将中止。That is, the value of maxTransactionLockRequestTimeoutMillis must at least cover the time required for the in-progress transaction and the pending DDL operation to complete.也就是说，maxTransactionLockRequestTimeoutMillis的值必须至少涵盖正在进行的事务和挂起的DDL操作完成所需的时间。

In-progress Transactions and Write Conflicts进行中事务和写入冲突

If a transaction is in progress and a write outside the transaction modifies a document that an operation in the transaction later tries to modify, the transaction aborts because of a write conflict.如果事务正在进行中，并且事务外部的写入修改了事务中的操作稍后试图修改的文档，则事务会因写入冲突而中止。

If a transaction is in progress and has taken a lock to modify a document, when a write outside the transaction tries to modify the same document, the write waits until the transaction ends.如果事务正在进行中并且已锁定以修改文档，则当事务外部的写入尝试修改同一文档时，写入将等待事务结束。

In-progress Transactions and Stale Reads正在进行的事务和过时的读取

Read operations inside a transaction can return old data, which is known as a stale read. 事务内的读取操作可能会返回旧数据，这被称为过时读取。Read operations inside a transaction are not guaranteed to see writes performed by other committed transactions or non-transactional writes. For example, consider the following sequence:事务内的读取操作不能保证看到其他已提交事务或非事务性写入执行的写入。例如，考虑以下顺序：

1. A transaction is in-progress.事务正在进行中。
2. A write outside the transaction deletes a document.事务外的写入操作会删除文档。
3. A read operation inside the transaction can read the now-deleted document since the operation uses a snapshot from before the write operation.事务中的读取操作可以读取现在已删除的文档，因为该操作使用了写入操作之前的快照。

To avoid stale reads inside transactions for a single document, you can use the db.collection.findOneAndUpdate() method. 为了避免对单个文档的事务内部进行过时的读取，您可以使用db.collection.findOneAndUpdate()方法。The following mongosh example demonstrates how you can use db.collection.findOneAndUpdate() to take a write lock and ensure that your reads are up to date:下面的mongosh示例演示了如何使用db.collection.findOneAndUpdate()获取写锁并确保读取是最新的：

db.getSiblingDB("hr").employees.insertOne(
   { _id: 1, status: "Active" }
)

session = db.getMongo().startSession( { readPreference: { mode: "primary" } } )

session.startTransaction( { readConcern: { level: "snapshot" }, writeConcern: { w: "majority" } } )

employeesCollection = session.getDatabase("hr").employees

employeeDoc = employeesCollection.findOneAndUpdate(
   { _id: 1, status: "Active" },
   { $set: { lockId: ObjectId() } },
   { returnNewDocument: true }
)

session.commitTransaction()

In-progress Transactions and Chunk Migration进行中事务和块迁移

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" wait until all writes of a transaction are visible.使用读取关注"snapshot"或"linearizable"的外部读取会等到事务的所有写入都可见。
• Outside reads that are part of causally consistent sessions (those that include afterClusterTime) wait until all writes of a transaction are visible.作为因果一致会话一部分的外部读取（包括afterClusterTime）会等待事务的所有写入可见。
• Outside reads using other read concerns do not wait until all writes of a transaction are visible, but instead read the before-transaction version of the documents.使用其他读取关注的外部读取不会等到事务的所有写入都可见，而是读取文档的事务前版本。

Additional Information附加信息