[SERVER-61205] WiredTiger.wt, connection: read checksum error for 4096B block at offset 53248: block header checksum doesn't match expected checksum Created: 03/Nov/21  Updated: 29/Nov/21  Resolved: 29/Nov/21

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

Type: Bug Priority: Major - P3
Reporter: Vincent Man Assignee: Edwin Zhou
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File WiredTiger.turtle     File WiredTiger.wt     File WiredTiger.wt.orig     Text File mongodb-1.log     Text File mongodb.log    
Operating System: ALL
Participants:

 Description   

Hi

we are unable to restart mongod instance after system reboot.

we follow the notice, try use --repair to repair some files.

but after that, mongod launch success, but database was disppeared

one more file was create, WiredTiger.wt.orig

mongodb v4.4.1



 Comments   
Comment by Edwin Zhou [ 29/Nov/21 ]

Hi vincent.manest@gmail.com,

We haven’t heard back from you for some time, so I’m going to close this ticket. If this is still an issue for you, please provide additional information and we will reopen the ticket.

Best,
Edwin

Comment by Edwin Zhou [ 18/Nov/21 ]

Hi vincent.manest@gmail.com,

We still need additional information to diagnose the problem. If this is still an issue for you, would you please let us know if you were able to make a complete copy of the database's $dbpath directory to safeguard so that you can work off of the current $dbpath? Depending on the state of your backup, we may be able to attempt a metadata repair on the files on your backup files.

Best,
Edwin

Comment by Edwin Zhou [ 03/Nov/21 ]

Hi dario.desimone@gmail.com,

This error message leads us to suspect some form of corruption. Prior to running --repair, were you able to make a complete copy of the database's $dbpath directory to safeguard so that you can work off of the current $dbpath?

The ideal resolution is to perform a clean resync from an unaffected node.

Given your provided metadata files, I've attempted a metadata-only repair effort using internal tools. Unfortunately this attempt failed and we're unable to repair this corruption.

To avoid a problem like this in the future, it is our strong recommendation to:

Best,
Edwin

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