[SERVER-38824] Investigate dropped collections coming back into existence Created: 03/Jan/19 Updated: 06/Dec/22 |
|
| Status: | Backlog |
| Project: | Core Server |
| Component/s: | Storage |
| Affects Version/s: | 4.0.5 |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Daniel Gottlieb (Inactive) | Assignee: | Backlog - Storage Engines Team |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | storage-engines | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||
| Assigned Teams: |
Storage Engines
|
||||||||||||||||
| Participants: | |||||||||||||||||
| Case: | (copied to CRM) | ||||||||||||||||
| Description |
|
There are cases where a collection dropped from the _mdb_catalog reappear. The hypothesis is that the following sequence performed by a secondary:
can result in the collection reappearing in state 2 when those individual updates are pushed to WT's lookaside table. The common manifestation is that a restart of the mongod process will fail with fatal assertion code 34433 because the _mdb_catalog refers to a table that was dropped from WT. |
| Comments |
| Comment by Jocelyn del Prado [ 05/Apr/19 ] |
|
Switching this to the backlog fix version and raised the priority of the 2 linked tickets. |
| Comment by Daniel Gottlieb (Inactive) [ 16/Jan/19 ] |
|
Yep |
| Comment by Alexander Gorrod [ 15/Jan/19 ] |
|
The two related WiredTiger tickets are being picked up at the moment - once the WT tickets are resolved, we will revisit this, and hopefully have a path forward. Does that make sense daniel.gottlieb? |