[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: |
|
||||||||
| Participants: | |||||||||
| Description |
|
Would be nice if rollbacks could continue through db drops. See log:
|
| 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. |