Uploaded image for project: 'MongoDB Database Tools'
  1. MongoDB Database Tools
  2. TOOLS-1155

mongodump should produce errors when some documents can not be fetched

    • Type: Icon: Bug Bug
    • Resolution: Done
    • Priority: Icon: Major - P3 Major - P3
    • None
    • Affects Version/s: None
    • Component/s: None
    • None
    • Environment:
      mongod running with corrupted database + mongodump

      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.

            Assignee:
            Unassigned Unassigned
            Reporter:
            alex.komyagin@mongodb.com Alexander Komyagin (Inactive)
            Votes:
            1 Vote for this issue
            Watchers:
            8 Start watching this issue

              Created:
              Updated:
              Resolved: