[SERVER-31436] dropDatabase must check `ReplicationCoordinator::canAcceptWritesFor` after reacquiring global lock - MongoDB Jira

XML

Word

Printable

JSON

Details

Type: Bug
Status: Closed
Priority: Major - P3
Resolution: Fixed
Affects Version/s: None
Fix Version/s: 3.6.0-rc1
Component/s: Replication
Labels:
- neweng

Backwards Compatibility:
Fully Compatible
Operating System:
ALL
Sprint:
Repl 2017-11-13
Linked BF Score:
0

Description

After waiting for all collection drops to replicate to a majority of the replica set, the dropDatabase command reacquires the global lock before completing the rest of the database drop and logging the dropDatabase oplog entry. It is possible that the primary has stepped down while waiting for the collection drops. We should check ReplicationCoordinator::canAcceptWritesFor after reacquiring the global lock to avoid hitting a fatal assertion in logOp() in this case.

Attachments

Issue Links

is related to

SERVER-29874 Two Phase Drops: dropDatabase does not work with applyOps

Closed

SERVER-29876 Two Phase Drops: dropDatabase should always wait for pending collection drops to complete

Closed

SERVER-29277 Two Phase Drops: implement dropDatabase changes to support 2-phase drops

Closed

related to

SERVER-32402 dropDatabase after step down can cause fassert

Closed

Activity

People

Assignee:: Benety Goh

Reporter:: Benety Goh

Participants:: Benety Goh, Githook User

Votes:: 0 Vote for this issue

Watchers:: 2 Start watching this issue

Dates

Created:: Oct 06 2017 02:22:46 PM UTC

Updated:: Dec 28 2017 11:05:45 PM UTC

Resolved:: Oct 16 2017 05:05:29 PM UTC