[SERVER-28200] Recoverable Rollback: Extend dropIndexes oplog entry to include dropped index spec Created: 06/Mar/17 Updated: 25/Aug/17 Resolved: 14/Mar/17 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Replication |
| Affects Version/s: | None |
| Fix Version/s: | 3.5.5 |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Benety Goh | Assignee: | Judah Schvimer |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||
| Sprint: | Repl 2017-03-06, Repl 2017-03-27 | ||||||||||||||||
| Participants: | |||||||||||||||||
| Linked BF Score: | 0 | ||||||||||||||||
| Description |
|
Currently, rolling back a dropIndexes operation in the oplog requires a full resync of the collection documents and metadata. This ticket proposes to extend the oplog entry for deleteIndexes to include the specification of the index that is being dropped so that we can recreate the index on rollback without any communication with the sync source. Additionally, if there are multiple indexes dropped, a separate oplog entry should be generated for each dropped index. |
| Comments |
| Comment by Githook User [ 14/Mar/17 ] |
|
Author: {u'username': u'judahschvimer', u'name': u'Judah Schvimer', u'email': u'judah@mongodb.com'}Message: |
| Comment by Benety Goh [ 08/Mar/17 ] |
|
We should examine if {deleteIndexes: <collection>, index: '*'}is handled correctly when we are ready to work on SERVER-27096 |
| Comment by Judah Schvimer [ 06/Mar/17 ] |
|
An alternative solution would be to have an array of index specs if we drop multiple indexes. This might risk exceeding the 16MB document limit, depending on current constraints on index spec size. |
| Comment by Judah Schvimer [ 06/Mar/17 ] |
|
Separating the oplog entry into one for each index makes it so we no longer replicate dropIndexes atomically. This may not be a problem. Per my discussion with Benety, a solution is to log the full operation so that replication is atomic, and then also log each individual index drop for rollback. |