-
Type: Bug
-
Resolution: Duplicate
-
Priority: Major - P3
-
None
-
Affects Version/s: 2.2.0
-
Component/s: Tools
-
Environment:Running a sharded configuration of Mongo 2.2 in Amazon EC2 with 2 replica sets of 2 db nodes each, 1 arbiter for each replSet and 3 config servers.
The config servers and arbiters are EC2 t1.micro instances.
The mongo replica set nodes are EC2 m1.large instances.
All servers are running:
Description: Ubuntu 12.04.1 LTS
Release: 12.04
Codename: precise
Linux 3.2.0-23-virtual #36-Ubuntu SMP Tue Apr 10 22:29:03 UTC 2012 x86_64 x86_64 x86_64 GNU/LinuxRunning a sharded configuration of Mongo 2.2 in Amazon EC2 with 2 replica sets of 2 db nodes each, 1 arbiter for each replSet and 3 config servers. The config servers and arbiters are EC2 t1.micro instances. The mongo replica set nodes are EC2 m1.large instances. All servers are running: Description: Ubuntu 12.04.1 LTS Release: 12.04 Codename: precise Linux 3.2.0-23-virtual #36-Ubuntu SMP Tue Apr 10 22:29:03 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
-
Linux
We experience intermittent failures when doing a mongodump of our production database with errors similar to the one below:
Mon Oct 1 15:30:15 Metadata for Briteblue.activities to /mnt/mongobackup/Briteblue/activities.metadata.json
Mon Oct 1 15:30:15 Briteblue.system.profile to /mnt/mongobackup/Briteblue/system.profile.bson
Mon Oct 1 15:30:15 doing snapshot query
Mon Oct 1 15:30:15 760 objects
Mon Oct 1 15:30:15 Metadata for Briteblue.system.profile to /mnt/mongobackup/Briteblue/system.profile.metadata.json
Mon Oct 1 15:30:15 Assertion: 10320:BSONElement: bad type 95
0xad0f71 0x67f28b 0x55beab 0x7036ef 0x5635d3 0x566ed0 0x568fd1 0xb42d62 0x5545f2 0x7fabf3ca076d 0x554459
mongodump(_ZN5mongo15printStackTraceERSo+0x21) [0xad0f71]
mongodump(_ZN5mongo11msgassertedEiPKc+0x9b) [0x67f28b]
mongodump(_ZNK5mongo11BSONElement4sizeEv+0x1cb) [0x55beab]
mongodump(_ZNK5mongo7BSONObj10jsonStringENS_16JsonStringFormatEi+0xff) [0x7036ef]
mongodump(_ZN4Dump17writeMetadataFileESsN5boost11filesystem210basic_pathISsNS1_11path_traitsEEESt3mapISsN5mongo7BSONObjESt4lessISsESaISt4pairIKSsS7_EEESt8multimapISsS7_S9_SD_E+0x363) [0x5635d3]
mongodump(_ZN4Dump2goESsN5boost11filesystem210basic_pathISsNS1_11path_traitsEEE+0x1e50) [0x566ed0]
mongodump(_ZN4Dump3runEv+0x1b61) [0x568fd1]
mongodump(_ZN5mongo4Tool4mainEiPPc+0x1712) [0xb42d62]
mongodump(main+0x32) [0x5545f2]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xed) [0x7fabf3ca076d]
mongodump(__gxx_personality_v0+0x421) [0x554459]
assertion: 10320 BSONElement: bad type 95
Some observations:
The dump always fails when dumping the entire db.
If a dump of the db fails against a specific collection, more often than not, dumping the offending collection on its own is successful
A successful dump of an individual collection may fail 5 minutes later on the same collection
The "BSONElement: bad type" error value changes every time; values seen include 54, 95, 110, 118
The error occurs using mongodump 2.2 on Ubuntu 12 x64, Ubuntu 10 x86, Windows 2008R2, against mongos or directly against a primary node in the replica set.
Oddly, doing a mongodump with the 2.0.7 binary against the very same 2.2 database works perfectly (as does the restore using mongorestore 2.2)
Running db.collection.validate() shows no errors for any of the collections.
We are trying not to having to resort to running a db repair.
- duplicates
-
SERVER-6877 mongodump raises BSONElement: bad type 117 error
- Closed