Skip to content

Commit 14383e8

Browse files
author
Dave
authored
DOCS-14892 distributed deadlock in transactions v5.3 (#678)
* DOCS-14892 Distributed deadlock in transactions * DOCS-14892 Distributed deadlock in transactions * Staging fixes * Staging fixes * Review feedback * Staging fixes * Review feedback * Review feedback
1 parent c189584 commit 14383e8

File tree

2 files changed

+60
-0
lines changed

2 files changed

+60
-0
lines changed

source/reference/parameters.txt

Lines changed: 51 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -3085,6 +3085,57 @@ Sharding Parameters
30853085

30863086
`Live Migration Protocol <https://github.com/mongodb/mongo/blob/master/src/mongo/db/s/README.md#the-live-migration-protocol>`__
30873087

3088+
.. parameter:: metadataRefreshInTransactionMaxWaitBehindCritSecMS
3089+
3090+
.. versionadded:: 5.2 (*Also available starting in 5.1.0, 5.0.4*)
3091+
3092+
*Type*: integer
3093+
3094+
*Default*: 500
3095+
3096+
|mongod-only|
3097+
3098+
Limits the time a shard waits for a critical section within a
3099+
transaction.
3100+
3101+
When a query accesses a shard, a :ref:`chunk migration
3102+
<migrate-chunks-sharded-cluster>` or :ref:`DDL operation
3103+
<transactions-operations-ddl>` may already hold the critical
3104+
section for the collection. If the query finds the critical
3105+
section is taken, the shard waits until the critical section has
3106+
been released. When the shard returns control to :binary:`mongos`,
3107+
:binary:`mongos` retries the query. However, if a multi-shard
3108+
transaction interacts with an operation that takes the critical
3109+
section on multiple shards, the interaction can result in a
3110+
distributed deadlock.
3111+
3112+
3113+
:parameter:`metadataRefreshInTransactionMaxWaitBehindCritSecMS`
3114+
limits the maximum time a shard waits within a transaction for the
3115+
critical section to be released.
3116+
3117+
To reduce the maximum wait time for the critical section within a
3118+
transaction, lower the the value of
3119+
:parameter:`metadataRefreshInTransactionMaxWaitBehindCritSecMS`.
3120+
3121+
.. warning::
3122+
3123+
If :parameter:`metadataRefreshInTransactionMaxWaitBehindCritSecMS`
3124+
is too low, :binary:`mongos` could use all of its retry attempts
3125+
and return an error.
3126+
3127+
You can set
3128+
:parameter:`metadataRefreshInTransactionMaxWaitBehindCritSecMS` at
3129+
startup and during runtime.
3130+
3131+
For example, to set :parameter:`metadataRefreshInTransactionMaxWaitBehindCritSecMS`
3132+
to 400 milliseconds:
3133+
3134+
.. code-block:: javascript
3135+
3136+
db.adminCommand( { setParameter: 1, metadataRefreshInTransactionMaxWaitBehindCritSecMS: 400 } )
3137+
3138+
30883139
.. parameter:: readHedgingMode
30893140

30903141
.. versionadded:: 4.4

source/release-notes/5.2.txt

Lines changed: 9 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -204,6 +204,15 @@ Starting in MongoDB 5.2, the :dbcommand:`setAllowMigrations` command:
204204
<sharding-chunk-migration-manual>` from committing
205205
- Excludes the collection from new balancer rounds
206206

207+
Limit Wait Time For Critical Section
208+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
209+
210+
Starting in MongoDB 5.2 (and 5.0.4, 5.1.0)
211+
212+
The :parameter:`metadataRefreshInTransactionMaxWaitBehindCritSecMS`
213+
parameter limits the time a shard waits for a critical section within a
214+
transaction.
215+
207216
.. _5.2-rel-notes-general:
208217

209218
General Improvements

0 commit comments

Comments
 (0)