Loading...

XML

Word

Printable

JSON

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

Backwards Compatibility:
Fully Compatible
Operating System:
ALL
Sprint:
Repl 2017-11-13
Linked BF Score:
0
Confidence Status:
None
Work Order:
3

Aha! Reference:
None
Tracking Level:
None
Risk Status:
None
Exec Notes:
None
Goal Name:
None
Goal Link:
None

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.

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

Assignee:: Benety Goh
Reporter:: Benety Goh
Participants:: Benety Goh, Githook User
Votes:: 0 Vote for this issue
Watchers:: 2 Start watching this issue

Created:: Oct 06 2017 02:22:46 PM UTC
Updated:: Oct 30 2023 11:13:01 PM UTC
Resolved:: Oct 16 2017 05:05:29 PM UTC

Details

Description

Attachments

Issue Links

Activity

People

Dates