MongoDB分片集群中的注意事项

MongoDB Manual (Version 4.2）>  Transactions  >  Production Considerations (Sharded Clusters)

本次我们将从以下几方面介绍分片集群中的注意事项。

分片事务及MongoDB驱动

性能

Read Concerns读关注

Write Concerns写关注

仲裁者

三成员 主-从-仲裁 分片

备份回档

块迁移

提交期间的读请求

与副本索引的交互

其他信息

从版本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时使用事务（ 例如使用内存存储引擎的带有投票成员的分片）。

注意

不管为事务指定的写关注，分片群集事务的提交操作都包含一些部分，这些部分包括：用写关注。

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

Cannot find shardId the chunk belonged to at cluster time ...

也可以看看

shardingStatistics.countDonorMoveChunkLockTimeout

在提交期间进行外部读取

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

外部读取时使用读策略snapshot或“ linearizable”， 或者是一致性的会话的一部分（例如，包括afterClusterTime）等待事务的所有写入均可见。

外部读取使用其他读策略时，不会等待事务的所有写入都可见，而是会读取可用集合的事务前版本。

也可以看看事务及原子性

与副本索引的交互

对于集合上的复制索引版本（而不是滚动索引版本），一旦针对主副本集成员发布了索引构建完成后，从成员将应用关联的oplog条目并开始索引构建。在构建索引时，从数据库等待应用以后的任何oplog条目，包括在构建期间提交的分布式事务。如果复制停顿的时间长于oplog窗口，则c从副本将失去同步并需要重新同步才能恢复。

为了最大程度地减少分片事务和索引之间的潜在交互，请考虑以下在分片集群上构建索引的策略之一：

在维护窗口期间建立索引，在该窗口中，应用程序停止针对要建立索引的集合发出分布式事务。

使用滚动索引构建过程构建索引，如在分片群集上构建索引中所述。

增加每个副本集成员上的oplog大小，以减轻由于复制索引构建而导致不同步的可能性。

其他信息

参考产品说明

.https://docs.mongodb.com/v4.2/core/transactions-production-consideration/

https://docs.mongodb.com/v4.2/core/transactions-sharded-clusters/

译者：王金铷MongoDB中文社区翻译小组成员

往期发布：