3

I have a mongodb running on windows azure linux vm,

The database is located on the system drive and i wish to move it to another hard drive since there is not enough space there.

I found out this post : Changing MongoDB data store directory

These seems to be a fine solution suggested there, yet there is another person who mentioned something about copying the files,

My database is live and getting data all the time, how can i make this proccess with lossing the least data possible ?

Thanks,

Community
  • 1
  • 1
Matan L
  • 997
  • 3
  • 14
  • 35
  • If this is a replica set the easiest way to do this is start an instance of MongoDB on the new storage and add to the replica set. It will sync your data set from the primary. Once caught up you could make the instance on the new storage your primary and retire the former one. – James Wahlin Apr 09 '14 at 20:02
  • 1
    This is a standalone instance and not a replica set, what would you suggest me to do ? – Matan L Apr 09 '14 at 22:08

1 Answers1

5

First, if this is a production system you really need to be running this as a replica set. Running production databases on singleton mongodb instances is not a best practice. I would consider 2 full members plus 1 arbiter the minimum production set up.

If you want to go the replica set route, you can first convert this instance to a replica set:

http://docs.mongodb.org/manual/tutorial/convert-standalone-to-replica-set/

this should have minimal down time.

Then add 2 new instances with the correct storage set up. After they sync you will have a full 3 member set. You can then fail over to one of the new instances. Remove this bad instance from the replica set. Finally I'd add an arbiter instance to get you back up to 3 members of the replica set while keeping costs down.

If on the other hand you do not want to run as a replica set, I'd shutdown mongod on this instance, copy the files over to the new directory structure on another appropriate volume, change the config to point to it (either changing dbpath or using a symlink) and then startup again. Downtime will be largely a factor of the size of your existing database, so the sooner you do this the better.

However - I will stress this again - if you are looking for little to no down time with mongoDB you need to use a replica set.

John Petrone
  • 26,943
  • 6
  • 63
  • 68
  • Thank you very much for your detailed answer, this is a production database that we are using as a test (first no sql in our company) for solving a problem that fits mongo really good. its size is ~4GB and we do not see a use for having 3 servers for this for now, in the future we might do it, so i will go for the standalone option. do you have any estimation on how long this should take ? or any "unexpected" issues i might encounter during the proccess ? – Matan L Apr 10 '14 at 10:38
  • The risk you run with a standalone is loss of service should an issue arise with the database or server and loss of data if there is a data corrupting event. You will also incur downtime when performing operational procedures like database upgrade. If you can afford these risks/costs then you are fine as is. If you can't afford to lose this data I would make sure you have a solid backup process in place. – James Wahlin Apr 10 '14 at 13:13
  • +1 on always using a replica set. It is the only real way to both keep the service running while healing instances and also to allow for migrating disks, configuration, etc. You can use 3 of the new "Basic" VM types if you're looking to save money. – Jeff Wilcox Apr 10 '14 at 18:00
  • @MatanL I would not expect a copy of 4GB of files to take a significant length of time assuming you have reasonably higher performance storage volumes. Changing the configuration to point to the new data location is trivial and new configuration files can be created ahead of time, so most of the work is in correctly copying the files. – John Petrone Apr 10 '14 at 18:10
  • One additional comment - while not recommended for production use you can run a replica set all on a single server. The configs need to point to different data directories and mongo needs to listen on different ports, but if forced to run on a single server you would at least have a way to upgrade without service interruption, a better way to take backups and some safety if your primary mongod process were to fail for some reason (which can happen). Right now to upgrade to mongodb 2.6 you will require downtime, something you can avoid with a replica set. – John Petrone Apr 10 '14 at 18:14
  • Okay, as i see you all extremely recommend going to replica set i would have that subject rechecked. thanks. – Matan L Apr 12 '14 at 11:55