Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

We're testing deployment of a web app on Amazon's EC2 which uses MongoDB for the database. Mongo recommends using at least 3 nodes for replication for data integrity. Although this is testing, we'd like to test with replication to see how the system handles failures, so we need 3 EC2 instances at a minimum. I'd also like to see that web load balancing works as well.

My thinking is to create 3 medium EC2 instances all running both MongoDB and the web server. We'll have a load balancer distribute web requests between the three servers, and configure Mongo to use them as replicas for data integrity.

Are there any problems with this plan?

share|improve this question
up vote 4 down vote accepted

Since this is a "testing" phase, ans we all know that testing is the model we use for production, I'd remind you that MongoDB is memory-heavy, and uses filesystem cache to map files.

If your web application is also memory-heavy, and there is not enough memory for your application AND MongoDB to run, then MongoDB will be the one that suffers, since the kernel will evict FS cache due to requests for private/resident pages in memory.

As long as you are keeping an eye on your memory usage pattern (including kernel-level buffers/caches, and mongod page faults), you should be fine.

share|improve this answer

no seems fine for testing failover of mongo and replicasets.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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