[SERVER-16215] mongodump --repair does not terminate gracefully under WiredTiger Created: 18/Nov/14  Updated: 24/Jan/15  Resolved: 13/Jan/15

Status: Closed
Project: Core Server
Component/s: Storage, Tools
Affects Version/s: 2.8.0-rc0
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Bruce Lucas (Inactive) Assignee: Spencer Jackson
Resolution: Won't Fix Votes: 0
Labels: wiredtiger
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Backwards Compatibility: Fully Compatible
Operating System: ALL
Participants:

 Description   

When the repair cursor used by mongodump --repair hits a damaged region, mongod aborts with a checksum error:

2014-11-18T08:05:55.281-0500 E STORAGE  [conn1] WiredTiger (0) [1416315955:281461][41709:0x10a284000], file:collection-2-8144621339125293100.wt, cursor.next: read checksum error [4096B @ 17756160, 2609031421 != 63499111]

causing mongodump to terminate abruptly:

> mongodump --repair
2014-11-18T08:01:01.498-0500	writing repair of test.c to dump/test/c.bson
2014-11-18T08:01:01.513-0500	repair error: error reading collection: EOF

The resulting .bson file is then abruptly terminated:

> bsondump dump/test/c.bson >/dev/null
2014-11-18T08:04:29.177-0500	unexpected EOF

Aside from looking bad, this leaves quite a few (several thousand in my test) recoverable records unrecovered.



 Comments   
Comment by Daniel Pasette (Inactive) [ 13/Jan/15 ]

mongodump --repair is not supported when using the wiredTiger storage engine. Instead, use mongod --repair or the repair command from the mongo shell.

Comment by Eliot Horowitz (Inactive) [ 18/Nov/14 ]

Probably

Comment by Eliot Horowitz (Inactive) [ 18/Nov/14 ]

I'm not sure repair cursors are really going to be the way we handle corrupted WT docs. They were pretty suspect before, and remain so.
I.e. it can return garbage docs that are valid bson, but wrong.
So i'm not sure we really want to change this.
mongod --repair will be the preferred route.

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