2

I have been trying to find a way to do this but cannot, and I have a feeling there isn't an easy way to do what I want.

I have been testing using mongodump | mongorestore as a way to avoid creating an actual stored set of files, which is very useful on a cloud-based service. So far, I have been testing this by specifying the same db, although it technically isn't necessary, like so...

mongodump -h hostname -d dumpdb --excludeCollection bigcollection --archive | mongorestore --archive -d dumpdb --drop
mongodump -h hostname -d dumpdb -c bigcollection --archive --queryFile onlythese.json | mongorestore --archive -d dumpdb -c bigcollection --drop

I have found that these options work best for me; when I attempt to specify the -o - option with the single db, with the --archive removed, I was having some issues, but since this worked, I didn't mess with it. Since I was restoring to the same db and because only the collections that were in there at the time were restored, I realize I can knock off the -d and -c in both mongorestore commands. But, it was easy to do, and is the set up for the next step... All I wanted to do was restore the specified db in two steps, to a db of a different name, like so...

mongodump -h hostname -d dumpdb --excludeCollection bigcollection --archive | mongorestore --archive -d restoredb --drop
mongodump -h hostname -d dumpdb -c bigcollection --archive --queryFile onlythese.json | mongorestore --archive -d restoredb -c bigcollection --drop

The dump works fine, but restore does not. Based on the limited documentation, my assumption is that the dump db and restore db need to be the same for this to work; if the db specified in mongorestore is not in the dump, it just won't restore. I find this to be rather annoying; my other thought was to restore the db as is, and just copy it to the other db. I have thought about using other tools such as mongo-dump-stream, but considering everything was working swimmingly so far, I was hoping that it would work with the default tools. On another point, I did dump the archive to a file (like so: > dumpdb.tar) and attempt to restore from there (like so --archive=dumpdb.tar) which is how I confirmed that the db needed to be in the dump.

Any suggestions/comments/hacks would be welcome.

Community
  • 1
  • 1
Omar Ahmad
  • 61
  • 4
  • You are on the wrong site. [dba.stackexchange.com](http://dba.stackechange.com) is for questions about database admin and backups. StackOverflow is for "programming" questions, which this is not. – Neil Lunn Apr 23 '16 at 00:28

2 Answers2

4

As of version 3.4 of mongorestore, you can accomplish this using the --nsFrom and --nsTo options, which provide a pattern-based way to manipulate the names of your collections and/or dbs between the source and destination.

For example, to dump from a database named dumpdb into a new database named restoredb:

mongodump -h hostname -d dumpdb --archive | mongorestore --archive --nsFrom "dumpdb.*" --nsTo "restoredb.*" --drop

More from the mongodb docs: https://docs.mongodb.com/manual/reference/program/mongorestore/#change-collections-namespaces-during-restore

Tyler Hsu
  • 171
  • 5
0

I haven't really found an answer to this, but, based on mongodb Jira, it looks like this is an open issue, and a feature request on their timeline, to actually be able to restore to a different DB than what you started with.

In the meantime, I came up with a not-so-great, but okay solution: as the archive file also contains the metadata, which in the code for mongorestore shows that that is all that is changed, you can replace the name of the DB in the binary file stream with one of the same length; so, my code now looks like this:

mongodump -h hostname -d dumpdb --excludeCollection bigcollection --archive | bbe -e "s/$(echo -n dumpdb | xxd -g 0 -u -ps -c 256 | sed -r 's/[A-F0-9]{2}/\\x&/g')\x00/$(echo -n rstrdb | xxd -g 0 -u -ps -c 256 | sed -r 's/[A-F0-9]{2}/\\x&/g')\x00/g" | mongorestore --archive --drop

You'll notice that I used bbe and dropped the -d tag, because this just changes the name of db in the archived metadata, and will restore to the new one. The obvious issue here is that you cannot change the length gracefully; a longer name won't work, and shorter requires padding, which probably won't work. Otherwise, for those looking for a better solution than dumping to a file, or running a copyDatabase command (don't do it!), this is a workable solution.

Omar Ahmad
  • 61
  • 4