diff options
author | Moustafa Maher Khalil <m.maher@mongodb.com> | 2022-01-11 21:49:55 +0000 |
---|---|---|
committer | Evergreen Agent <no-reply@evergreen.mongodb.com> | 2022-02-19 01:28:18 +0000 |
commit | 45d84929f04b99b882195c3b6c0333c91438e108 (patch) | |
tree | 432ddfb42a40d0f11b13efe7f6c5b64123f525e4 | |
parent | 78858e1cb9b2c69cbd3c122e4ff7fee2246bd3ab (diff) | |
download | mongo-45d84929f04b99b882195c3b6c0333c91438e108.tar.gz |
SERVER-62379 Fix deadlock between ReplicationCoordinator and BackgroundSync on stepUp
-rw-r--r-- | src/mongo/db/repl/bgsync.cpp | 6 |
1 files changed, 5 insertions, 1 deletions
diff --git a/src/mongo/db/repl/bgsync.cpp b/src/mongo/db/repl/bgsync.cpp index 0cd8e9afd4e..425f0df28cd 100644 --- a/src/mongo/db/repl/bgsync.cpp +++ b/src/mongo/db/repl/bgsync.cpp @@ -482,6 +482,10 @@ void BackgroundSync::_produce() { { auto opCtx = cc().makeOperationContext(); + // Calling getMyLastAppliedOpTime has to be outside bgsync mutex, to preserve proper lock + // ordering because it acquires replication coordinator's mutex . + auto lastAppliedOpTime = _replCoord->getMyLastAppliedOpTime(); + // Check if the producer has been stopped so that we can prevent setting the applied point // after step up has already cleared it. We need to acquire the collection lock before the // mutex to preserve proper lock ordering. @@ -499,7 +503,7 @@ void BackgroundSync::_produce() { // TODO SERVER-53642: With Lock Free Reads we may have readers on lastAppliedOpTime so // we cannot use this timestamp in a write. _replicationProcess->getConsistencyMarkers()->setAppliedThrough( - opCtx.get(), _replCoord->getMyLastAppliedOpTime(), false); + opCtx.get(), lastAppliedOpTime, false); } } |