[SERVER-20984] Support rolling back database drops Created: 16/Oct/15  Updated: 03/Aug/17  Resolved: 03/Aug/17

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

Type: Improvement Priority: Major - P3
Reporter: Eric Daniels (Inactive) Assignee: Judah Schvimer
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
duplicates SERVER-29691 Two Phase Drops: implement database d... Closed
Participants:

 Description   

Would be nice if rollbacks could continue through db drops.

See log:

2015-10-16T18:14:54.219+0000 F REPL     [rsBackgroundSync] rollback : can't rollback drop database full resync will be required
2015-10-16T18:14:54.219+0000 I REPL     [rsBackgroundSync] { dropDatabase: 1 }
2015-10-16T18:14:54.219+0000 E REPL     [rsBackgroundSync] replica set fatal exception
2015-10-16T18:14:54.220+0000 I REPL     [rsBackgroundSync] rollback finished
2015-10-16T18:14:54.220+0000 I -        [rsBackgroundSync] Fatal assertion 28723 UnrecoverableRollbackError need to rollback, but unable to determine common point betweenlocal and remote oplog: replica set fatal exception @ 18752



 Comments   
Comment by Eric Milkie [ 17/Oct/15 ]

Yes. The larger solution to rollback, on storage engines that support snapshotting, is to simply restore the database instance to the committed snapshot, and then play forward any remaining committed ops. This avoids most of the current problematic rollback logic for "undoing" drops of collections, indexes, and other metadata changes.

Comment by Andy Schwerin [ 17/Oct/15 ]

I think the solution is to defer actually dropping the database or collection until the majority of voting nodes confirm receiving the drop.

Generated at Thu Feb 08 03:55:53 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.