8

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?

Improve this question
6
  • Are this standalone or replica sets?
    – SqlWorldWide
    Commented Jun 7, 2017 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
    Commented Jun 7, 2017 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.
    – SqlWorldWide
    Commented Jun 7, 2017 at 19:57
  • As stated before you can use the "rolling upgrade procedure" mongodb.com/blog/post/your-ultimate-guide-to-rolling-upgrades
    – Markus
    Commented Jun 7, 2017 at 20:09
  • 1
    @SqlWorldWide by far should be a separate and accepted answer (not a comment)
    – natanavra
    Commented Nov 15, 2018 at 7:56

1 Answer 1

Reset to default
5

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.

Improve this answer
0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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