MongoDb clustering: recipes and tall tales from a high-traffic production system.



Our production environment used an established, well-known Hybrid Cloud hosting company who offered the best IO bang for the buck., including all the bells and whistles: Web-based interface, Ubuntu support, good support and better performance than their competitors. The gotcha was that their massive lead in IO performance was due to their use of SAN storage mounted to each vm via iSCSI.

As it turns out, once in a while this storage link would 'hiccup' every once in a while. The effect on MySQL was catastrophic, IOWAIT would go through the roof, and although the box was still up, it was dead as a doornail in terms of workload. It took us a day or tow to figure out what was happening, and then to also figure out that this was happening on the MongoDb replicas as well.


NoSQL databases such as MongoDb are a data-storage paradigm shift that can enrage and confuse people used to RDBMS’. Having run MongoDb and MySQL in a high-traffic application, I will share with you how we used Mongo, how it works in a multi-server setup with replica sets and sharding, and how to craft your client code to prevent problems at 200,000 requests per hour.

Speaking experience