[SERVER-32106] Migration of txn oplog entries can trigger fassert in secondary replication Created: 28/Nov/17 Updated: 30/Oct/23 Resolved: 30/Nov/17 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | 3.6.0-rc6 |
| Fix Version/s: | 3.6.1, 3.7.1 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Randolph Tan | Assignee: | Randolph Tan |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | SWNA | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
|
||||
| Issue Links: |
|
||||
| Backwards Compatibility: | Fully Compatible | ||||
| Operating System: | ALL | ||||
| Backport Requested: |
v3.6
|
||||
| Sprint: | Sharding 2018-01-01 | ||||
| Participants: | |||||
| Description |
|
During migration, oplog entries generated by transactions are converted to type 'n' no-op entries and sent to the destination side. These new oplog entries also retain the original fields, like 'ns' and 'uuid'. If the collection with the same name is drop and re-sharded, the secondaries will trigger an fassert when processing this type 'n' entries because the uuid no longer exists. Example log in secondary:
|
| Comments |
| Comment by Githook User [ 19/Dec/17 ] |
|
Author: {'name': 'Randolph Tan', 'email': 'randolph@10gen.com', 'username': 'renctan'}Message: (cherry picked from commit dbb028ac3b40a4fcfd9502402aec729f26004fbe) |
| Comment by Githook User [ 30/Nov/17 ] |
|
Author: {'name': 'Randolph Tan', 'username': 'renctan', 'email': 'randolph@10gen.com'}Message: |