Mongodb vertical scaling on ec2

[Niceguy23]

So I got my replica set up and running on an m3.large instance.

If I would like to vertically scale the replica set, will it be as easy as resizing the machine to a m3.2xlarge for example?

Should I change some mongodb configuration in order to let it use more memory or cpu?

[s.molinari]

You have a replica set in one VM? Doesn't that totally defeat the purpose of the ability to have high availability? I mean, if that one VM goes down, then so does all your replicas.

Also AFAIK, AWS EC2 doesn't allow vertical scaling either.

Usually, to vertically scale, you would add the new bigger nodes to the replica set, 

http://docs.mongodb.org/manual/tutorial/expand-replica-set/ 

then stop the mongod in the old nodes and reconfigure the old primary with the new secondaries, so that the primary must step down. This will cause a re-election (and your only down time) and you are off and running on newer bigger nodes.

http://docs.mongodb.org/manual/tutorial/remove-replica-set-member/#remove-a-member-using-rs-reconfig

(anyone with more experience, please correct me should I be wrong.)

Scott 

[Niceguy23]

I didn't explain myself accurately :

Each node of the replica set is on a different VM instance.

What I wanted to really ask, is - if I stop the primary node, resize it and then restart it again - will that be enough? Or mongodb should know about this extra CPU power / RAM that was just added?

Thanks.

[Stephen Steneker]

On Tuesday, 3 February 2015 06:42:28 UTC+11, Niceguy23 wrote:

I didn't explain myself accurately :

Each node of the replica set is on a different VM instance.

What I wanted to really ask, is - if I stop the primary node, resize it and then restart it again - will that be enough? Or mongodb should know about this extra CPU power / RAM that was just added?

Hi,

Thanks for clarifying your deployment. If you restart an existing replica set member with different RAM or CPU resources there are no specific configuration changes for MongoDB.

In the EC2 case vertical scaling often means provisioning and migrating to a new instance, which is the approach that Scott referenced. With reserved instances you sometimes have options within the same instance family (http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ri-modification-instancemove.html), but generally you will end up having to add the replacement node to the replica set with a new internal hostname.

Assuming your MongoDB data volume is on EBS and you want to continue using the same storage type (rather than upgrading storage along with the instance size) you can stop the original instance, detach the EBS volume, and re-attach to your new instance.

A few considerations for scaling vertically (or upgrading replica set nodes);

 - your data-bearing replica set nodes should generally have similar resource configurations to allow for failover (i.e. you don't want to have an upgraded primary and less capable secondaries)

 - to minimize downtime you would normally upgrade one secondary at a time, wait for it to be successfully added/synced, and finally step down and upgrade the primary

 - restarting instances has the side effect of clearing your working set from memory; for a very active deployment you should consider the possible performance impact while the new member starts loading data and perhaps warm up data before upgrading the next secondary (for example, see: http://blog.parse.com/2013/03/07/techniques-for-warming-up-mongodb/).

Regards,

Stephen

[Niceguy23]

Thanks for the help!

[s.molinari]

Yes, thanks Stephen!

Scott