Database Manual / Transactions

Production Considerations (Sharded Clusters)生产考虑因素(分片集群)

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.生产注意事项。