I have to move a 200GB MongoDB from one server to another (both Windows 2016 OS). During this operation, it is assumed that the accompanying program will be offline, so no need to worry about inconsistent data, but I need to minimize the downtime. Diskspace is not an issue, but downtime is. I've tried testing it with mongodump and mongorestore, but that took almost 20 hours to complete, which seems pretty ridiculous. I'm looking at a couple other options:

  1. Use copydb
  2. Take a snapshot of the disk and/or copy the db folder directly to the new server and point the installation to that by changing the path in the .conf file.

I'm guessing #2 would be fastest if it will work, but I haven't found any real confirmation that it works on a Windows platform. Has anyone successfully done this? If so, is it as simple as I described? As mentioned, MongoDB and its accompanying program can be turned off completely for this operation.

Alternatively, can anyone give me a ballpark figure on how long copydb takes versus a mongodump/mongorestore operation?

  • Are this standalone or replica sets? Jun 7 '17 at 19:19
  • Standalone. Want to move the location of the MongoDB from its current location (sharing a server with other programs) to its own server. So the copy/clone will be taking over for the current instance.
    – schneiju
    Jun 7 '17 at 19:54
  • 3
    No #2 definitely works. #3 option. Make it a replica set. Add the new server as new node. Once sync is completed, take a short downtime. Start new server as standalone. Repoint application to new server. Jun 7 '17 at 19:57
  • As stated before you can use the "rolling upgrade procedure" mongodb.com/blog/post/your-ultimate-guide-to-rolling-upgrades
    – Markus
    Jun 7 '17 at 20:09
  • 1
    @SqlWorldWide by far should be a separate and accepted answer (not a comment)
    – natanavra
    Nov 15 '18 at 7:56

Final solution: We went with option #2 - turning off MongoDB and manually copying the database files over to the new server. It worked like a charm. For future database migrations and changes, I will probably be making a replica set as suggested by @SqlWorldWide and @Markus. That looks like it would definitely the best solution for someone who has time to properly plan a migration.

  • 1
    You can mark your answer as the accepted answer to close out this question, schneiju. It helps to prevent it from getting bumped to the homepage when the site doesn't think it got successfully resolved. Oct 19 '17 at 13:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.