[SERVER-34372] Drop collection command with majority write concern should wait until two-phase drop finishes Created: 06/Apr/18  Updated: 29/Oct/23  Resolved: 19/Apr/18

Status: Closed
Project: Core Server
Component/s: Replication
Affects Version/s: None
Fix Version/s: 3.7.6

Type: Improvement Priority: Major - P3
Reporter: Siyuan Zhou Assignee: Benety Goh
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
is depended on by SERVER-33244 Make all lock acquisitions for transa... Closed
Duplicate
is duplicated by SERVER-35613 Two-phase drop can prevent subsequent... Closed
Related
related to SERVER-34349 Wait for drop to be majority committe... Closed
related to SERVER-34717 Performance regression in dropDatabase Closed
is related to SERVER-38744 w:majority collection drops may try t... Closed
is related to SERVER-34069 Postpone 2nd phase of collection drop... Closed
is related to SERVER-34452 Wait for 2-phase drop to finish in tr... Closed
Backwards Compatibility: Fully Compatible
Sprint: Repl 2018-04-23
Participants:
Linked BF Score: 13

 Description   

Waiting for the drop command gets replicated to a majority doesn't guarantee the drop completes on the primary, so after the command returns, the drop-pending collection reaper will actually drop the collection, which takes the database lock in X mode. The asynchronous DB lock in X mode may be unexpected to users, especially transaction users, because it will block (or abort when SERVER-33244 is done) transactions waiting for the DB lock.



 Comments   
Comment by Githook User [ 19/Apr/18 ]

Author:

{'email': 'benety@mongodb.com', 'username': 'benety', 'name': 'Benety Goh'}

Message: SERVER-34372 fix transaction test to rely on new write concern behavior for pending drops
Branch: master
https://github.com/mongodb/mongo/commit/2c8fe56c6501035063871930eda192bb78928c74

Comment by Githook User [ 18/Apr/18 ]

Author:

{'email': 'benety@mongodb.com', 'username': 'benety', 'name': 'Benety Goh'}

Message: SERVER-34372 awaiting majority write concern waits for pending drops to complete
Branch: master
https://github.com/mongodb/mongo/commit/1eea6ecc4ac973a3bb81151482ca5451e38ab172

Comment by Githook User [ 18/Apr/18 ]

Author:

{'name': 'Benety Goh', 'email': 'benety@mongodb.com', 'username': 'benety'}

Message: SERVER-34372 add ReplicationCoordinator::signalDropPendingCollectionsRemovedFromStorage()
Branch: master
https://github.com/mongodb/mongo/commit/a6411b4e7ac800272d7835fe77c6bc55516efa03

Comment by Githook User [ 18/Apr/18 ]

Author:

{'name': 'Benety Goh', 'email': 'benety@mongodb.com', 'username': 'benety'}

Message: SERVER-34372 add ReplicationCoordinatorExternalState::getEarliestDropPendingOpTime()
Branch: master
https://github.com/mongodb/mongo/commit/91274b50a3f58f69ce9016e14628f490d1df29a2

Comment by Githook User [ 17/Apr/18 ]

Author:

{'name': 'Benety Goh', 'email': 'benety@mongodb.com', 'username': 'benety'}

Message: SERVER-34372 add js test for checking drop pending collection behavior with write concern majority

This commit also adds a dropPendingCollectionReaperHang fail point used in the test.
Branch: master
https://github.com/mongodb/mongo/commit/84f56ce808fc985f2c340f05fc7f7e63ccbdb8e7

Comment by Spencer Brody (Inactive) [ 13/Apr/18 ]

We've decided not to do SERVER-34069, so re-opening this ticket to help enable testing efforts

Comment by Benety Goh [ 13/Apr/18 ]

The proposed fix, combined with SERVER-34069, will impact performance on operations with majority write concern. We will fix the tests instead. See SERVER-34452.

Comment by Gregory McKeon (Inactive) [ 11/Apr/18 ]

spencer, this blocks a 3.7.4 ticket so I'm bumping it to 3.7.4

Comment by Siyuan Zhou [ 06/Apr/18 ]

When this is done, we will be able to remove TwoPhaseDropCollectionTest.waitForDropToComplete() in transaction tests.

Generated at Thu Feb 08 04:36:27 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.