You can perform multi-document transactions on sharded clusters.您可以在分片集群上执行多文档事务。
The following page lists concerns specific to running transactions on a sharded cluster. These concerns are in addition to those listed in Production Considerations.下一页列出了在分片集群上运行事务所特有的问题。这些问题是生产注意事项中列出的问题之外的问题。一>
>Performance性能
Single Shard单分片
Transactions that target a single shard should have the same performance as replica-set transactions.针对单个分片的事务应具有与副本集事务相同的性能。
Multiple Shards多个分片
Transactions that affect multiple shards incur a greater performance cost.影响多个分片的事务会产生更大的性能成本。
Note
On a sharded cluster, transactions that span multiple shards will error and abort if any involved shard contains an arbiter.在分片集群上,如果任何涉及的分片包含仲裁器,则跨越多个分片的事务将出错并中止。
Time Limit时间限制
To specify a time limit, specify a 要指定时间限制,请在maxTimeMS limit on commitTransaction.commitTransaction上指定maxTimeMS限制。
If 如果未指定maxTimeMS is unspecified, MongoDB will use the transactionLifetimeLimitSeconds.maxTimeMS,MongoDB将使用transactionLifetimeLimitSeconds。
If maxTimeMS is specified but would result in transaction that exceeds transactionLifetimeLimitSeconds, MongoDB will use the transactionLifetimeLimitSeconds.
To modify transactionLifetimeLimitSeconds for a sharded cluster, the parameter must be modified for all shard replica set members.
Read Concerns读取关注
Multi-document transactions support "local", "majority", and "snapshot" read concern levels.
For transactions on a sharded cluster, only the "snapshot" read concern provides a consistent snapshot across multiple shards.
For more information on read concern and transactions, see Transactions and Read Concern.
Write Concerns
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).
Note
Regardless of the write concern specified for the transaction, the commit operation for a sharded cluster transaction includes some parts that use {w: "majority", j: true} write concern.
Arbiters
You cannot change a shard key using a transaction if the replica set has an arbiter. Arbiters cannot participate in the data operations required for multi-shard transactions.
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.
Backups and Restores
Warning
To use mongodump and mongorestore as a backup strategy for sharded clusters, see Back Up a Self-Managed Sharded Cluster with a Database Dump.
Sharded clusters can also use one of the following coordinated backup and restore processes, which maintain the atomicity guarantees of transactions across shards:
Chunk Migrations
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"wait until all writes of a transaction are visible. - Outside reads that are part of causally consistent sessions (those that include afterClusterTime) wait until all writes of a transaction are visible.
Outside reads using other read concerns do not wait until all writes of a transaction are visible, but instead read the before-transaction version of the documents.使用其他读取关注的外部读取不会等到事务的所有写入都可见,而是读取文档的事务前版本。
Additional Information附加信息
See also Production Considerations.生产注意事项。