生产注意事项

可用性¶

• 在版本4.0中，MongoDB支持副本集上的多文档事务。

• 在4.2版中，MongoDB引入了分布式事务，它增加了对分片群集上多文档事务的支持，并合并了对副本集上多文档事务的现有支持。

  要在MongoDB 4.2部署（副本集和分片群集）上使用事务，客户端必须使用针对MongoDB 4.2更新的MongoDB驱动程序。

功能兼容性¶

要使用事务， 部署的所有成员的featureCompatibilityVersion必须至少为：

要检查成员的fCV，请连接到该成员并运行以下命令：

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

有关更多信息，请参见 setFeatureCompatibilityVersion参考页。

运行时限制¶

默认情况下，事务的运行时必须少于一分钟。您可以transactionLifetimeLimitSeconds为 mongod实例修改此限制 。对于分片群集，必须为所有分片副本集成员修改参数。超过此限制的事务将被视为已过期，并且将通过定期清除过程中止。

对于分片群集，您还可以maxTimeMS在上指定一个限制 commitTransaction。有关更多信息，请参阅分片群集事务时间限制。

OPLOG大小限制¶

从4.2版开始，

MongoDB创建所需数量的oplog条目以封装事务中的所有写操作，而不是事务中所有写操作的单个条目。这消除了单个oplog条目对其所有写操作施加的事务的16MB总大小限制。尽管删除了总大小限制，但每个oplog条目仍必须在16MB的BSON文档大小限制内。

在4.0版中，

如果事务包含任何写操作，则MongoDB 在提交时将创建单个操作日志（操作日志）条目。即，事务中的各个操作没有相应的oplog条目。相反，单个操作日志条目包含事务中的所有写操作。交易的oplog条目必须在BSON文档大小限制内16MB。

WiredTiger缓存¶

为防止存储缓存压力对性能造成负面影响：

• 放弃交易时，中止交易。
• 当您在事务中进行单个操作时遇到错误时，请中止并重试该事务。

这transactionLifetimeLimitSeconds还确保了过期的事务会定期中止，以减轻存储缓存的压力。

事务和安全性¶

• 如果使用访问控制运行，则必须对事务中的 操作具有特权。
• 如果运行带审核功能，则仍将审核中止的事务中的操作。但是，没有审核事件指示事务中止。

碎片配置限制¶

您不能在具有writeConcernMajorityJournalDefault设置为的分片的分片群集上运行事务false （例如，具有使用内存存储引擎的投票成员的分片）。

分片集群和仲裁器¶

如果任何事务操作读取或写入包含仲裁程序的分片，则其写操作跨越多个分片的事务将出错并中止。

另请参阅3成员主次仲裁器体系结构，以了解对已禁用读取关注多数的分片的事务限制。

三成员主次仲裁器架构¶

对于具有主次仲裁器（PSA）体系结构的三成员副本集或具有三成员PSA分片的分片群集，您可能已禁用了“读取多数”以避免担心缓存压力。

在分片集群上

• 如果事务涉及已禁用读关注度“多数”的分片，则不能"snapshot"对事务使用读关注度。您只能使用已读关注"local"或 "majority"用于事务。如果使用读取关注"snapshot"，则事务错误并中止。

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

• 如果任何事务的读或写操作涉及禁用了读取关注的分片，则其写操作跨越多个分片的事务将出错并中止 "majority"。

在副本集上，

您可以指定读取关注点"local"， "majority"或者"snapshot"甚至在副本集中已禁用读取关注点“多数”。

但是，如果您打算过渡到具有禁用读关注多数分片的分片群集，则可能希望避免使用读关注"snapshot"。

获取锁¶

默认情况下，事务等待长达5毫秒，以获取事务中的操作所需的锁。如果事务无法在5毫秒内获得其所需的锁，则事务中止。

事务在中止或提交时释放所有锁。

待处理的DDL操作和事务¶

如果正在进行多文档事务，则影响相同数据库或集合的新DDL操作将在事务后面等待。尽管存在这些未决DDL操作，但是与未决DDL操作访问相同数据库或集合的新事务无法获取所需的锁，并且将在等待后中止maxTransactionLockRequestTimeoutMillis。另外，访问相同数据库或集合的新的非事务操作将阻塞，直到达到maxTimeMS极限为止 。

请考虑以下情形：

需要收集锁的DDL操作

在进行中的事务正在数据库中的employees集合上执行各种CRUD操作的同时hr，管理员db.collection.createIndex()对employees集合发出DDL操作。 createIndex()需要对集合使用排他的集合锁。

在进行中的事务完成之前，该 createIndex()操作必须等待获取锁。任何影响employees 收集并在createIndex() 挂起时启动的新事务都必须等到createIndex()完成后再进行 。

待处理的createIndex()DDL操作不会影响hr数据库中其他集合上的事务。例如，数据库中contractors集合上的新事务hr可以正常启动和完成。

需要数据库锁定的DDL操作

在进行中的事务employees对hr数据库中的集合执行各种CRUD操作时，管理员collMod对contractors同一数据库中的集合执行DDL操作。 collMod需要对父hr 数据库进行数据库锁定。

在进行中的事务完成之前，该collMod 操作必须等待获取锁。任何影响hr数据库或其任何集合并在collMod挂起时启动的新事务都必须等到collMod完成之后再进行 。

在这两种情况下，如果DDL操作的未决状态超过 maxTransactionLockRequestTimeoutMillis，则在该操作之后等待的未决事务将中止。也就是说，的值 maxTransactionLockRequestTimeoutMillis必须至少涵盖进行中的事务和挂起的DDL操作完成所需的时间。

进行中的事务和写冲突¶

如果事务正在进行中，并且在事务外部进行写操作会修改文档，而该文件后来在事务中尝试修改，则事务会由于写冲突而中止。

如果事务正在进行中并且已锁定修改文档，则在事务外部进行写尝试修改同一文档时，该写操作将一直等到事务结束。

进行中的事务和陈旧的读取¶

事务内的读取操作可以返回陈旧的数据。也就是说，不能保证事务内的读取操作会看到其他已提交事务执行的写操作或非事务性写操作。例如，请考虑以下顺序：1）正在进行事务； 2）在事务外部进行写入会删除文档； 3）事务内部的读取操作能够读取已删除的文档，因为该操作使用快照从写之前开始。

为避免对单个文档进行过时的内部事务读取，可以使用该db.collection.findOneAndUpdate()方法。例如：

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 }
);

• 如果员工单据已在事务外更改，则事务中止。
• 如果员工文档未更改，则事务处理将返回该文档并锁定该文档。

正在进行的事务和块迁移¶

块迁移在某些阶段获得排他的收集锁。

如果正在进行的事务锁定了集合，并且涉及该集合的块迁移开始，则这些迁移阶段必须等待事务释放对集合的锁定，从而影响块迁移的性能。

如果大块迁移与事务交织（例如，如果在大块迁移已在进行的同时启动事务，并且迁移在事务锁定集合之前完成），则提交期间的事务错误并中止。

根据两个操作的交错方式，包括一些示例错误（错误消息已被缩写）：

• an error from cluster data placement change ... migration commit in progress for <namespace>
• Cannot find shardId the chunk belonged to at cluster time ...

提交期间的外部读取¶

在提交事务期间，外部读取操作可能会尝试读取将由事务修改的相同文档。如果事务写入多个分片，则在尝试进行分片提交时

• 使用读关注度snapshot或 "linearizable"或属于因果一致会话（即，包括afterClusterTime）的外部读取等待事务的所有写入均可见。
• 使用其他读取问题的外部读取不等待事务的所有写入可见，而是读取可用文档的交易前版本。

错误¶

其他信息¶