Comment on page
生产注意事项
- 在4.0版本，MongoDB支持副本集上的多文档事务。
- 在4.2版本，MongoDB引入了分布式事务，增加了对分片集群上多文档事务的支持，并整合了已有的对副本集上多文档事务的支持。要在MongoDB 4.2（副本集和分片集群）中使用事务，客户端必须使用为MongoDB 4.2更新的MongoDB驱动程序。
注意分布式事务和多文档事务从MongoDB 4.2开始，这两个术语是同义词。分布式事务是指分片集群和副本集上的多文档事务。从MongoDB 4.2开始，多文档事务（无论是在分片集群上还是副本集上）也称为分布式事务。
部署方式 | 最小 featureCompatibilityVersion |
Replica Set | 4.0 |
Sharded Cluster | 4.2 |
要检查成员的fCV，可以连接到该成员并运行以下命令：
db.adminCommand( { getParameter: 1, featureCompatibilityVersion: 1 } )
默认情况下，事务的运行时间必须少于一分钟。可以使用
transactionLifetimeLimitSeconds修改[mongod](https:/ /docs.mongodb.com/v4.4/reference/program/mongod/#mongodb-binary-bin.mongod)实例的该限制。对于分片集群，必须为所有分片副本集成员修改该参数。超过此限制的事务将被视为已过期，并将被定期清理的进程中止掉。- 从4.2版本开始，MongoDB会根据需要创建尽可能多的oplog条目来封装事务中的所有写操作，而不是为事务中的所有写操作创建一个条目。这移除了单oplog条目对其所有写操作施加的事务总大小为16MB的限制。尽管删除了总大小限制，但每个oplog条目仍然必须满足BSON文档16MB大小的限制。
- 在4.0版本，如果事务包含任何写操作，MongoDB会在提交时创建一个oplog（操作日志）条目。也就是说，事务中的各个操作没有对应的oplog条目。相反，由单个oplog条目包含事务中的所有写操作。事务的oplog条目必须满足BSON文档16MB大小的限制。
为了防止存储缓存压力对性能产生负面影响：
- 当你放弃一个事务时，中止掉事务。
- 当你在事务中的单个操作过程中遇到错误时，中止并重试该事务。
如果任何事务操作从一个包含仲裁节点的分片中读取或写入，其写操作跨越多个分片的事务将出错并中止。
- 在分片集群上，如果事务涉及具有已禁用读关注
"majority"的分片，则不能在事务中使用读关注"snapshot"。只能在事务中使用读关注"local"或"majority"。如果使用读关注"snapshot"，事务会报错并中止。readConcern level 'snapshot' is not supported in sharded clusters when enableMajorityReadConcern=false。如果任何事务的读或写操作涉及已禁用读关注"majority"的分片，其写操作跨越多个分片的事务将出错并中止。 - 在副本集上，即使已经禁用读关注
"majority"，也可以在副本集上定义读关注"local"、"majority"和"snapshot"。但是，如果计划过渡到禁用读关注"majority"分片的分片集群上，那么可能会希望避免使用读关注"snapshot"。
提示要检查读关注"majority"是否被禁用，可以在mongod实例上运行db.serverStatus()并检查storageEngine. supportCommittedReads字段。如果为false，则表示已禁用读关注"majority"。
默认情况下，事务最多等待5毫秒来获取事务中操作所需的锁。如果事务无法在5毫秒内获得所需的锁，事务将中止。
事务在中止或提交时释放所有锁。
提示
可以使用
maxTransactionLockRequestTimeoutMillis参数来调整事务等待获取锁的时间。增加maxTransactionLockRequestTimeoutMillis允许事务中的操作等待指定的时间来获取所需的锁。这有助于避免在瞬时并发锁请求时事务发生中止，例如快速运行的元数据操作。但是，这可能会延迟死锁事务操作的中止。如果一个多文档事务正在执行，则影响相同数据库或集合的新DDL操作会等待该事务完成。当这些挂起的DDL操作存在时，访问与挂起的DDL操作相同的数据库或集合的新事务无法获得所需的锁，并将在等待
maxTransactionLockRequestTimeoutMillis后超时中止。此外，访问相同数据库或集合的新的非事务操作将被阻塞，直到它们达到maxTimeMS限制。考虑以下场景：
- 请求集合锁的DDL操作当一个正在进行的事务对
hr数据库中employees集合执行各种CRUD操作时，管理员在employees集合上发起[db.collection.createIndex()](https://docs.mongodb.com/ v4.4/reference/method/db.collection.createIndex/#mongodb-method-db.collection.createIndex)DDL操作。createIndex()命令会请求该集合上的排他集合锁。直到正在进行的事务完成，createIndex()操作必须等待获取锁。任何影响employees集合且当createIndex()命令正在挂起时启动的新事务，都必须等到createIndex()完成才能执行。挂起的createIndex()DDL操作不会影响hr数据库中其他集合上的事务。例如，hr数据库中contractors集合上的新事务可以正常启动和完成。
在任何一种情况下，如果DDL操作保持挂起的时间超过
maxTransactionLockRequestTimeoutMillis，挂起的事务等待后面那个操作中止。即maxTransactionLockRequestTimeoutMillis的值必须至少涵盖正在进行的事务和挂起的DDL操作完成所需的时间。如果事务正在进行中，但事务外部的写入修改了该事务之后尝试修改的文档，则事务会因写入冲突而中止。
如果一个事务正在进行并且已经锁定修改文档，那么当事务外部的写操作试图修改同一个文档时，写操作会一直等到事务结束。
事务内的读取操作可能会返回陈旧数据。也就是说，事务内部的读操作不能保证看到其他已提交的事务或非事务性写入的内容。例如，假设有以下操作序列：1) 一个事务正在进行中 2) 事务外部的写操作删除了一个文档 3) 事务内部的读取操作能够读取已被删除的文档，因为该操作使用的是写操作发生之前的快照。
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 }
);
- 如果上面的employee文档在事务之外发生更改，则事务会中止。
- 如果上面的employee文档未更改，事务将返回文档并锁定该文档。
如果正在进行的事务持有集合上的锁，并且涉及该集合的块迁移刚开始，则这些迁移阶段必须等待事务释放集合上的锁，从而会影响块迁移的性能。
如果块迁移与事务交错进行（例如，如果事务在块迁移正在进行时开始，并且迁移在事务锁定集合之前完成），则事务在提交期间出错并中止。
根据两个操作的交错方式，一些示例错误包括（错误信息被缩略展示）：
an error from cluster data placement change ... migration commit in progress for <namespace>Cannot find shardId the chunk belonged to at cluster time ...
在事务提交期间，外部的读操作可能会尝试读取将被事务修改的相同文档。如果事务写入多个分片，则在跨分片提交尝试期间
- 使用其他读关注的外部读操作不会等待事务的所有写入可见，而是读取事务之前版本的可用文档。
要在MongoDB 4.2（副本集和分片集群）上使用事务，客户端必须使用为MongoDB 4.2更新的MongoDB驱动程序。
注意你的驱动程序可能会返回不同的错误。有关详细信息，请参阅驱动程序的文档。
错误码 | 错误信息 |
|---|---|
251 | cannot continue txnId -1 for session ... with txnId 1 |
50940 | cannot commit with no participants |
原文链接：https://docs.mongodb.com/manual/core/transactions-production-consideration/
译者：李正洋
最近更新 1yr ago