[SERVER-30150] Two Phase Drops: rolling back cross database renameCollections fails if there is both a dropTarget and dropSource collection Created: 14/Jul/17  Updated: 30/Oct/23  Resolved: 21/Jul/17

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

Type: Bug Priority: Major - P3
Reporter: Allison Chang 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-29959 Fix renameCollection step in rollback... Closed
Related
is related to SERVER-27992 replicate collection UUIDs Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Steps To Reproduce:

Triggered by rollback code in SERVER-29959.

Rolling back a renameCollection command where it drops two collections in the same oplog entry because it is a cross-database rename with both dropSource and dropTarget specified.

Sprint: Repl 2017-07-31
Participants:

 Description   

With a renameCollection command across databases, it is possible that two collections are specified to drop at the same optime, the dropSource and dropTarget collections. When we try to rollback these two drops using 2-phase drop, because the two drops have the same optime, the following error is thrown below. This is only a problem with renameCollection across databases. In a same database renames, only dropTarget can be present.

Failed to add drop-pending collection foo.system.drop.2i0t5.t with drop optime { ts: Timestamp 2000|0, t: 5 }. There is already an existing collection test.system.drop.2i0t5.t with the same drop optime.

The collections are in two different databases, "foo" and "test," but have the same optime, "2i0t5."



 Comments   
Comment by Githook User [ 21/Jul/17 ]

Author:

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

Message: SERVER-30150 DropPendingCollectionReaper::rollBackDropPendingCollection() rolls back at most one drop-pending collection.

Since it is now possible for multiple drop-pending collections (in different databases) to be linked
to the same drop optime, this function requires the fully qualified original collection optime to be
able to locate the correct entry in the drop pending collection multimap.
Branch: master
https://github.com/mongodb/mongo/commit/056e90b4fb8d6d50c011cbeb655bed3fdc0d9b0f

Comment by Githook User [ 20/Jul/17 ]

Author:

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

Message: SERVER-30150 DropPendingCollectionReaper supports multiple drop-pending namespaces per drop optime
Branch: master
https://github.com/mongodb/mongo/commit/808368314d1036b022334b67a9b2bd306daab840

Comment by Githook User [ 20/Jul/17 ]

Author:

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

Message: SERVER-30150 remove DropPendingCollectionReaper::dropCollectionAtOpTime()
Branch: master
https://github.com/mongodb/mongo/commit/878e55a460de02de2f0171d3e9e1bcfc12bb80cc

Comment by Judah Schvimer [ 14/Jul/17 ]

A renameCollection op can lead to two 2-phase-drops, one for dropTarget and one for dropSource. The machinery currently only allows for 1 collection to be dropped per OpTime.

Comment by Eric Milkie [ 14/Jul/17 ]

You can't have more than one collection with the same drop optime, can you?

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