[SERVER-24066] Ability to "mark" blocks as corrupt Created: 05/May/16  Updated: 06/Dec/22  Resolved: 01/Oct/18

Status: Closed
Project: Core Server
Component/s: Storage, WiredTiger
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major - P3
Reporter: Shakir Sadikali Assignee: Backlog - Storage Execution Team
Resolution: Done Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
Assigned Teams:
Storage Execution
Participants:

 Description   

We've encountered multiple instances of block corruption (not our fault) where the mongod refuses to start. It would be nice to be able to "mark" a block as corrupt and have some tooling available to us to "manually" bring just the corrupt block in either via file copy or some other means. If it's an index block, it would be nice to be able to simply tell mongod to kill the index and rebuild it. Either way, it would be nice to have an alternative to "nuking" the entire database and performing a full resync for a (presumably) single corrupt block.

Edit:
A customer just experienced an issue on a QA DB where they encountered a checksum error. It would have been nice to be able to bring the database up by having it ignore the "bad" block. Right now, they are in the process of running a repairDatabase.



 Comments   
Comment by Eric Milkie [ 08/Sep/21 ]

shakir.sadikali, in the time since this ticket was filed, we have enhanced the repair startup option to the server to handle more corrupt cases like this, which uses an enhanced "salvage" WiredTiger operation. If the latest version of the server failed to repair a particular type of corruption, we're interested in improving such situations; please file a new ticket with the details of what happened if you still have the info.

Comment by Shakir Sadikali [ 08/Sep/21 ]

This is still a problem actually.  We had a WT system experience block corruption where repairing didn't work.  The customer tried to export/dump data but weren't able to because the process kept hitting the corrupt document(s).  Being able  to explicitly mark blocks/documents as "being corrupt" would allow the mongod to gracefully ignore these and keep the export/dump in progress.

Comment by Eric Milkie [ 01/Oct/18 ]

I believe this request was MMAP-specific.

Generated at Thu Feb 08 04:05:17 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.