生产注意事项 (分片集群)
本页面中
从版本4.2开始,MongoDB提供了对分片群集执行多文档事务的功能。
下一页列出了特定于分片群集上运行事务的问题。除了产品注意事项中列出的那些关注点之外,还存在这些关注点。
分片事务及MongoDB驱动
_对于MongoDB 4.2部署(副本集和分片群集)上的事务,_客户必须使用为MongoDB 4.2更新的MongoDB驱动程序。
在具有多个mongos
实例的分片群集上,用MongoDB 4.0(而非MongoDB 4.2)执行事务更将会失败并可能导致错误,包括:
注意
您的驱动程序可能会返回其他错误。 有关详细信息,请参阅驱动程序的文档。
性能
单分片
针对单个分片的事务应具有与副本集事务相同的性能。
多分片
影响多个分片的事务会产生更高的性能成本。
注意
在分片群集上,如果任何涉及的分片包含仲裁者,那么跨越多个分片的事务将出错并中止。
时间限制
要指定时间限制,请在commitTransaction
上指定maxTimeMS
限制。
如果未指定maxTimeMS
,则MongoDB将使用transactionLifetimeLimitSeconds
。
如果指定maxTimeMS
,但会导致事务超过transactionLifetimeLimitSeconds
,则MongoDB将使用transactionLifetimeLimitSeconds
。
要为分片群集修改transactionLifetimeLimitSeconds
,必须为所有分片副本集成员修改参数。
Read Concerns 读关注
多文档事务支持local
,majority
和snapshot
读关注级别。
对于分片群集上的事务,只有snapshot
提供了读关注跨多个分片的一致性快照。
有关读关注和事务的更多信息,请参阅事务和读关注。
Write Concerns 写关注
您无法在writeConcernMajorityJournalDefault
设置为false
时使用事务( 例如使用内存存储引擎的带有投票成员的分片)。
注意
不管为事务指定的写关注,分片群集事务的提交操作都包含一些部分,这些部分包括: 用{w:“ majority”,j:true}
写关注。
Arbiters 仲裁者
如果任何事务操作读取或写入包含仲裁程序的分片,则其写操作跨越多个分片的事务将出错并中止。
另请参阅三成员 主-从-仲裁 分片,了解对分片禁用阅读大多数策略的事务限制。
三成员 主-从-仲裁 分片
对于具有三成员PSA的分片群集,您可以禁用读策略“majority”
(如--enableMajorityReadConcern false
或replication.enableMajorityReadConcern:false
)以避免缓存压力。
在分片集群上,
如果事务涉及的分片禁用读策略“majority”,则您不能设置读策略
“snapshot”
用于事务。对于该事务您只能使用读策略的“ local”
或“majority”
。如果使用读策略“ snapshot”
,则事务错误并中止。当enableMajorityReadConcern = false时,分片群集不支持`readConcern level'snapshot'。如果事务的任何读或写操作涉及到禁用读策略“majority”的分片,则其写操作跨越多个分片的事务将出错并中止。要检查读策略“majority”是否被禁用,
您可以运行
db.serverStatus()
并检查storageEngine.supportsCommittedReads
字段。如果为“ false”,则禁用阅读关注“多数”。
备份和恢复
警告
mongodump
和mongorestore
不能作为4.2+ 正在进行分片事务的分片群集的备份策略的一部分,因为使用mongodump
不维护跨分片事务的原子性保证。
对于具有正在进行中的分片事务的4.2+分片群集,请使用以下协调的备份和回档方案,这些方案确实维护了各个分片事务的原子性保证:
-MongoDB Atlas, -MongoDB Cloud Manager,或 -MongoDB Ops Manager。
Chunk Migrations 块迁移
块迁移在某些阶段获得会排他的集合锁。
如果正在进行的事务锁定了集合,并且涉及该集合的块迁移开始,则这些迁移阶段必须等待事务释放对集合的锁定,从而影响块迁移的性能。
如果大块迁移与事务交织(例如,如果在大块迁移已在进行的同时启动事务,并且迁移在事务锁定集合之前完成),则提交期间的事务错误并中止。
根据两个操作的交错方式,包括一些示例错误(错误消息已被缩写):
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)等待事务的所有写入均可见。外部读取使用其他读策略时,不会等待事务的所有写入都可见,而是会读取可用集合的事务前版本。
也可以看看事务及原子性
与副本索引的交互
对于集合上的复制索引版本(而不是滚动索引版本),一旦针对主副本集成员发布了索引构建完成后,从成员将应用关联的oplog条目并开始索引构建。在构建索引时,从数据库等待应用以后的任何oplog条目,包括在构建期间提交的分布式事务。如果复制停顿的时间长于oplog窗口,则c从副本将失去同步并需要重新同步才能恢复。
为了最大程度地减少分片事务和索引之间的潜在交互,请考虑以下在分片集群上构建索引的策略之一:
在维护窗口期间建立索引,在该窗口中,应用程序停止针对要建立索引的集合发出分布式事务。
使用滚动索引构建过程构建索引,如在分片群集上构建索引中所述。
增加每个副本集成员上的oplog大小,以减轻由于复制索引构建而导致不同步的可能性。
其他信息
参考 产品说明.
原文链接:https://docs.mongodb.com/v4.2/core/transactions-sharded-clusters/
译者:王金铷
最后更新于