-
Type: Bug
-
Resolution: Done
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
-
None
-
Environment:mongod running with corrupted database + mongodump
-
(copied to CRM)
When doing mongodump for corrupted namespace, it just dumps whatever documents it can fetch, producing no errors:
AD-MAC10G:ff alexander$ mongodump -d dummy
connected to: 127.0.0.1
Wed Dec 11 20:57:36.857 DATABASE: dummy to dump/dummy
Wed Dec 11 20:57:36.858 dummy.system.indexes to dump/dummy/system.indexes.bson
Wed Dec 11 20:57:36.858 3 objects
Wed Dec 11 20:57:36.858 dummy.acl to dump/dummy/acl.bson
Wed Dec 11 20:57:36.869 1 objects
Wed Dec 11 20:57:36.870 Metadata for dummy.acl to dump/dummy/acl.metadata.json
However, there were problems encountered during this dump:
Wed Dec 11 20:57:36.866 [conn7] Assertion: 10334:BSONObj size: 0 (0x00000000) is invalid. Size must be between 0 and 16793600(16MB) First element: EOO 0x10044c60b 0x100425fbe 0x10042607d 0x10007e3a7 0x1003b7a8c 0x1000d181f 0x1000df6a1 0x100240426 0x1001ea834 0x1001eee6b 0x10000b682 0x100441fd9 0x10047f1a5 0x7fff8bf847a2 0x7fff8bf711e1 0 mongod 0x000000010044c60b _ZN5mongo15printStackTraceERSo + 43 1 mongod 0x0000000100425fbe _ZN5mongo11msgassertedEiPKc + 174 2 mongod 0x000000010042607d _ZN5mongo11msgassertedEiRKSs + 29 3 mongod 0x000000010007e3a7 _ZNK5mongo7BSONObj14_assertInvalidEv + 1255 4 mongod 0x00000001003b7a8c _ZN5mongo7BSONObjC1EPKc + 44 5 mongod 0x00000001000d181f _ZN5mongo11BtreeCursor7currentEv + 45 6 mongod 0x00000001000df6a1 _ZNK5mongo12ClientCursor22fillQueryResultFromObjERNS_11_BufBuilderINS_16TrivialAllocatorEEEPKNS_12MatchDetailsE + 289 7 mongod 0x0000000100240426 _ZN5mongo14processGetMoreEPKcixRNS_5CurOpEiRbPb + 1222 8 mongod 0x00000001001ea834 _ZN5mongo15receivedGetMoreERNS_10DbResponseERNS_7MessageERNS_5CurOpE + 1492 9 mongod 0x00000001001eee6b _ZN5mongo16assembleResponseERNS_7MessageERNS_10DbResponseERKNS_11HostAndPortE + 4939 10 mongod 0x000000010000b682 _ZN5mongo16MyMessageHandler7processERNS_7MessageEPNS_21AbstractMessagingPortEPNS_9LastErrorE + 198 11 mongod 0x0000000100441fd9 _ZN5mongo17PortMessageServer17handleIncomingMsgEPv + 1657 12 mongod 0x000000010047f1a5 thread_proxy + 229 13 libsystem_c.dylib 0x00007fff8bf847a2 _pthread_start + 327 14 libsystem_c.dylib 0x00007fff8bf711e1 thread_start + 13 Wed Dec 11 20:57:36.869 [conn7] { $err: "BSONObj size: 0 (0x00000000) is invalid. Size must be between 0 and 16793600(16MB) First element: EOO", code: 10334 } Wed Dec 11 20:57:36.869 [conn7] getmore dummy.acl query: { query: {}, $snapshot: true } cursorid:1296896357636133 ntoreturn:0 keyUpdates:0 exception: BSONObj size: 0 (0x00000000) is invalid. Size must be between 0 and 16793600(16MB) First element: EOO code:10334 locks(micros) r:9125 nreturned:0 reslen:20 9ms Wed Dec 11 20:57:36.873 [conn7] end connection 127.0.0.1:56416 (0 connections now open)
Here is validate() output:
> db.acl.validate(true) { "ns" : "dummy.acl", "firstExtent" : "0:4000 ns:dummy.acl", "lastExtent" : "0:1a000 ns:dummy.acl", "extentCount" : 2, "extents" : [ { "loc" : "0:4000", "xnext" : "0:1a000", "xprev" : "null", "nsdiag" : "dummy.acl", "size" : 8192, "firstRecord" : "0:40b0", "lastRecord" : "0:5fc4" }, { "loc" : "0:1a000", "xnext" : "null", "xprev" : "0:4000", "nsdiag" : "dummy.acl", "size" : 36851712, "firstRecord" : "0:1a0b0", "lastRecord" : "0:2d70a8" } ], "datasize" : 2932264, "nrecords" : 10002, "lastExtentSize" : 36851712, "padding" : 1, "firstExtentDetails" : { "loc" : "0:4000", "xnext" : "0:1a000", "xprev" : "null", "nsdiag" : "dummy.acl", "size" : 8192, "firstRecord" : "0:40b0", "lastRecord" : "0:5fc4" }, "lastExtentDetails" : { "loc" : "0:1a000", "xnext" : "null", "xprev" : "0:4000", "nsdiag" : "dummy.acl", "size" : 36851712, "firstRecord" : "0:1a0b0", "lastRecord" : "0:2d70a8" }, "valid" : false, "errors" : [ "invalid bson object detected (see logs for more info)", "exception during validate" ], "advice" : "ns corrupt, requires repair", "ok" : 1 }
I believe this silent behavior of mongodump is misleading, and if scripted, can lead to unexpectedly inconsistent backups.
We should either throw errors, or compare the expected number of documents with the number of documents dumped.
- is related to
-
SERVER-1558 Documents should write checksum on write, verify checksum on read
- Closed
-
TOOLS-135 Add more verbose logging to mongorestore and mongodump
- Closed