Loading...

XML

Word

Printable

JSON

Type: Task
Resolution: Fixed
Priority: Major - P3
Fix Version/s: 3.5.10
Affects Version/s: None
Component/s: Replication
Labels:
None

Backwards Compatibility:
Fully Compatible
Sprint:
Repl 2017-06-19, Repl 2017-07-10
Confidence Status:
None
Work Order:
3
CAR Domain/s:
None

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

Collection drops are deferred until commit point advances to or past optime of drop operation. For database drops, we wait until all the collection drops are committed. While we are waiting for the collection drops to be committed, any writes to the database will be rejected. While the collection drop oplog entries are written to the oplog before they enter the drop-pending state, the dropDatabase oplog entry is only written to the oplog when all the collection drops are committed.

depends on

SERVER-29275 Two Phase Drops: implement collection drop commit logic

Closed

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-31436 dropDatabase must check `ReplicationCoordinator::canAcceptWritesFor` after reacquiring global lock

Closed

SERVER-32532 Two-phase dropDatabase may not replicate all collection drops before the database drop.

Closed

SERVER-29913 bulk_api.js should use runCommand() rather than DBQuery().next()

Closed

(1 related to)

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

Created:: May 18 2017 03:36:28 PM UTC
Updated:: Oct 30 2023 11:16:40 PM UTC
Resolved:: Jun 27 2017 07:11:46 PM UTC

Details

Description

Attachments

Issue Links

Forms

Activity

People

Dates