Production Considerations生产注意事项

Availability可用性

• In version 4.0, MongoDB supports multi-document transactions on replica sets.在4.0版本中，MongoDB支持副本集上的多文档事务。
• In version 4.2, MongoDB introduces distributed transactions, which adds support for multi-document transactions on sharded clusters and incorporates the existing support for multi-document transactions on replica sets.在4.2版本中，MongoDB引入了分布式事务，增加了对分片集群上多文档事务的支持，并整合了对副本集上多文档事务的现有支持。

  To use 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驱动程序。

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. 对于分片集群，您还可以指定commitTransaction的maxTimeMS限制。For more information, see Sharded Clusters Transactions Time Limit.有关详细信息，请参阅分片集群事务时间限制。

Oplog Size Limit操作日志大小限制

Starting in version 4.2,从版本4.2开始，

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. MongoDB根据需要创建尽可能多的oplog条目来封装事务中的所有写操作，而不是为事务中的全部写操作创建一个条目。This removes the 16MB total size limit for a transaction imposed by the single oplog entry for all its write operations. 这消除了单个操作日志条目对事务的所有写入操作所施加的16MB总大小限制。Although the total size limit is removed, each oplog entry still must be within the BSON document size limit of 16MB.尽管删除了总大小限制，但每个oplog条目仍然必须在BSON文档大小限制16MB的范围内。

In version 4.0,在版本4.0中，

MongoDB creates a single oplog (operations log) entry at the time of commit if the transaction contains any write operations. 如果事务包含任何写操作，MongoDB会在提交时创建一个oplog（操作日志）条目。That is, the individual operations in the transactions do not have a corresponding oplog entry. 也就是说，事务中的各个操作没有相应的oplog条目。Instead, a single oplog entry contains all of the write operations within a transaction. 相反，一个oplog条目包含事务中的所有写操作。The oplog entry for the transaction must be within the BSON document size limit of 16MB.事务的操作日志条目必须在BSON文档大小限制16MB的范围内。

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分片集群和仲裁器

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. 默认情况下，事务最多等待5毫秒来获取事务中操作所需的锁。If the transaction cannot acquire its required locks within the 5 milliseconds, the transaction aborts.如果事务无法在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. 如果多文档事务正在进行，则影响同一数据库或集合的新DDL操作将在事务之后等待。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操作相同的数据库或集合的新事务无法获得所需的锁，并且将在等待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. 当正在进行的事务对hr数据库中的employees集合执行各种CRUD操作时，管理员会对employees集合发出db.collection.createIndex()DDL操作。createIndex() requires an exclusive collection lock on the collection.需要对集合使用独占集合锁。

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. For example, a new transaction on the contractors collection in the hr database can start and complete as normal.挂起的createIndex()DDL操作不会影响hr数据库中其他集合上的事务。例如，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 collMod DDL operation against the contractors collection in the same database. 当正在进行的事务对hr数据库中的employees集合执行各种CRUD操作时，管理员会对同一数据库中的contractors集合发出collMod DDL操作。collMod requires a database lock on the parent hr database.需要对父hr数据库进行数据库锁定。

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

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 stale data. That is, 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 is able to read the now-deleted document since the operation is using a snapshot from before the write.例如，考虑以下顺序：1）事务正在进行中2）事务外部的写入会删除文档3）事务内部的读取操作能够读取现在已删除的文档，因为该操作使用的是写入之前的快照。

To avoid stale reads inside transactions for a single document, you can use the db.collection.findOneAndUpdate() method. 为了避免在单个文档的事务中进行过时的读取，可以使用db.collection.findOneAndUpdate()方法。For example:例如：

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

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

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

• If the employee document has changed outside the transaction, then the transaction aborts.如果员工文档在事务之外发生了更改，则事务将中止。
• If the employee document has not changed, the transaction returns the document and locks the document.如果员工文档没有更改，事务处理将返回文档并锁定文档。

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", 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.使用其他读取关注点的外部读取不会等待事务的所有写入都可见，而是读取可用文档的事务前版本。

Errors

Additional Information附加信息