[SERVER-43650] WiredTiger.wt: read checksum error for 28672B block at offset 2613248: block header checksum of 3584980580 doesn't match expected checksum of 1212880709 Created: 26/Sep/19  Updated: 10/Oct/19  Resolved: 10/Oct/19

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

Type: Bug Priority: Major - P3
Reporter: TRAN THOANG Assignee: Carl Champain (Inactive)
Resolution: Done Votes: 0
Labels: wt-repair-success
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File WiredTiger.turtle     File WiredTiger.wt     Text File error.log    
Participants:

 Description   

I had a problem when restart mongodb 3.6, pls help me. I had no any backup for them 



 Comments   
Comment by Carl Champain (Inactive) [ 10/Oct/19 ]

Thanks for getting back to me. I'm sorry you lost some data but glad the --repair worked!
I'm going to close this ticket as it is now resolved.

Comment by TRAN THOANG [ 10/Oct/19 ]

Thanks for support, 

I had use binary version 4.0.12 to repair files. Result, Our data files had repaired but partial data has been lost. But the results were good, our service was working again.

Thanks so much.

Comment by Carl Champain (Inactive) [ 09/Oct/19 ]

Hi tranthoang.vn@gmail.com,

Any updates on this issue?

Comment by Carl Champain (Inactive) [ 26/Sep/19 ]

Hi tranthoang.vn@gmail.com,

Thanks for the report.

Unfortunately, this error message leads us to suspect some form of physical corruption. Please make a complete copy of the database's $dbpath directory to work off of and safeguard the current $dbpath.
Our ability to determine the source of this corruption depends greatly on your ability to provide:

  1. The logs for the affected node, including before, leading up to, and after the first sign of corruption.
  2. A description of the underlying storage mechanism in use, including details like:
    1. What file system and/or volume management system is in use?
    2. Is data storage locally attached or network-attached?
    3. Are disks RAIDed and if so how?
    4. Are disks SSDs or HDDs?
  3. A description of your backup method, if any.
  4. A description of your disks have been recently checked for integrity?
  5. A history of the deployment, including:
    1. a timeline of version changes
    2. a timeline of hardware upgrade/downgrade cycles or configuration changes
    3. a timeline of disaster recovery or backup restoration activities
    4. a timeline of any manipulations of the underlying database files, including copies or moves, and information about whether mongod was running during each manipulation.

I see this node wasn't started as a replica set; therefore, the ideal resolution to perform a clean resync from an unaffected node will not work in your case.
Could you please download the 4.0.12 MongoDB binaries, use the 4.0.12 binary to run --repair against your data files, and then start the mongod using your original binaries?

Kind regards,
Carl

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