0

I am using mongodump and mongorestore in a replicated shard cluster in MongoDB 2.2. to get a backup and restore it.

First, I use mongodump for creating the dump of all the system, then I drop a concrete collection and restore it using mongorestore with the output of mongodump. After that, the collection is correct (the data it contains is correct and also the indexes), but the information about if this collection is sharded is lost. Before dropping it, the collection was sharded. After the restore, however, the collection was not sharded anymore.

I was wondering then if a way of keeping this information in backups exist. I was thinking that maybe sharded information for collection is kept in the admin database, but in the dump, admin folder is empty, and using show collections for this database I get nothing. Then I thought it could be kept in the metadata, but this would be strange, because I know that, in the metadata, the information about indexes is stored and indexes are correctly restored.

Then, I would like to know if it could be possible to keep this information using instead of mongodump + mongorestore, filesystem snapshots; or maybe still using mongodump and mongorestore but stopping the system or locking writing. I don't thing this last option could be the reason, because I am not performing writing operations while restoring even not being locking it, but just to give ideas.

I also would like to know if anyone is completely sure about if it is the case that this feature is still not available in the current version.

Any ideas?

Lucia Pasarin
  • 2,268
  • 1
  • 21
  • 37
  • 1
    Information about sharding is kept in a `config` database in config servers - three dedicated `mongod` instances. – ghik Feb 27 '13 at 23:11
  • I have been looking at chunks collection in config database and I think this is just what I was looking for. However, I tried restoring just this collection and it didn't work. Should I restore the whole config database for having my collection sharded again? – Lucia Pasarin Feb 28 '13 at 18:38
  • it's not clear exactly what process you would *like* to have. Are you trying to recreate your sharded cluster somewhere else? – Asya Kamsky Feb 28 '13 at 19:57

1 Answers1

1

If you are using mongodump to back up your sharded collection, are you sure it really needs to be sharded? Usually sharded collections are very large and mongodump would take too long to back it up.

What you can do to back up a large sharded collection is described here.

The key piece is to back up your config server as well as each shard - and do it as close to "simultaneously" as possible after having stopped balancing. Config DB is small so you should probably back it up very frequently anyway. Best way to back up large shards is via file snapshots.

Asya Kamsky
  • 41,784
  • 5
  • 109
  • 133
  • Mongodump is not taking too long for me and I don't want to use snapshots because they require file system tools (LVM). The fact of using config database was useful, I realized it keeps relevant information for me in chunks collection. Would restoring config database make my collection that was sharded, before dropping it, be sharded now again? – Lucia Pasarin Feb 28 '13 at 18:44
  • 1
    no, not unless you back up each shard individually. mongodump through mongos will "unify" sharded bits into a single dump of a collection. When you drop the collection from your sharded DB, you drop all of its information, including sharding information. – Asya Kamsky Feb 28 '13 at 19:56