mongodump doesn't export all documents

[Sören Kress]

Hi,

I am using mongodump to dump a database and to restore it on a different server. I've just accidentally realized that (at least) one document was not exported (or imported). I've tried it again and it's still not there in the restored version of the database.

I am using version 2.0.2, no sharding, just replication. I was connected directly to the master db, and the dump command was something like

mongodump -u dbuser -p password -d mydatabase -o .

and the restore: mongorestore -d mydatabase mydatabase

The document in question uses a standard ObjectId as primary key (so this 800 bytes key length limit as described on the mongodump man page should not be the cause for my problem).

Any ideas?

Thanks and best regards

Soeren

[Scott Hernandez]

Can you selectively dump, via query, one of the ones which is giving
you problems?

> --
> You received this message because you are subscribed to the Google Groups
> "mongodb-user" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/mongodb-user/-/X194KXuFJkwJ.
> To post to this group, send email to mongod...@googlegroups.com.
> To unsubscribe from this group, send email to
> mongodb-user...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/mongodb-user?hl=en.

[Sören Kress]

Yes, if I select the document via its id I mongodump dumps exactly one document (and looking into that bson file it seems like it is that document).

I've checked the old dump again, so the problem is not the dump, but the restore.

The dump exports 310 records. The restore says

Mon Mar  5 20:12:06 mydb/mycoll.bson

Mon Mar  5 20:12:06 going into namespace [mydb.mycoll]

310 objects found

but after importing there are only 307 documents:

> db.mycoll.find().size()

307

So, why does mongorestore skip 3 records?

Thanks

Soeren

[Scott Hernandez]

Can you check the server logs? You can restore just that one, with
more verbose logging, so you don't need to look at verbose logging for
the rest.

> --
> You received this message because you are subscribed to the Google Groups
> "mongodb-user" group.
> To view this discussion on the web visit

> https://groups.google.com/d/msg/mongodb-user/-/Hw3g1f5r3CsJ.

[Sören Kress]

Great - that helped a lot ... and sorry for stealing your time: was all my fault.

I only emptied the target database by simply deleting the documents within the collection (not removing the collections). That resulted in a unique index remaining in effect which does not exist on the source database. During the import the record was then discarded due to this unique index constraint violation.

Many thanks for your fast help.

Best regards

Soeren

[Glenn Maynard]

On Mon, Mar 5, 2012 at 1:53 PM, Sören Kress <soeren...@gmail.com> wrote:

Great - that helped a lot ... and sorry for stealing your time: was all my fault.

I only emptied the target database by simply deleting the documents within the collection (not removing the collections). That resulted in a unique index remaining in effect which does not exist on the source database. During the import the record was then discarded due to this unique index constraint violation.

FWIW, I'd expect records that are being dropped during an import to be visible by default, without having to dig into verbose logs, since it's probably important to know.

--
Glenn Maynard

[Scott Hernandez]

In many uses cases this is the preferred logging level. But I do
understand your point of view.

We should make it so that if you increase the logging of mongorestore
you will see this. Please feel free to file an issue for that
(http://jira.mongodb.org)

> --
> You received this message because you are subscribed to the Google Groups
> "mongodb-user" group.