O'Reilly logo

Resilience and Reliability on AWS by Jurg van Vliet, Flavia Paganelli, Jasper Geurtsen

Stay ahead with the world's most comprehensive technology and business learning platform.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, tutorials, and more.

Start Free Trial

No credit card required

Chapter 7. MongoDB

MongoDB is one of the more prominent NoSQL databases at this time. In our MongoDB implementations the requirements are that of an old-fashioned database:

  • Backup/restore
  • Easy (horizontal) scalability
  • Resilience to external influence
  • Reliability

You can find the entire project on github.

How It Works

For those who are new to MongoDB we’ll briefly introduce the key concepts with their implementation. We work with MongoDB Replica Set for high availability. We’ll use Route 53 to make sure it can be reached. We’ll use SimpleDB for backup administration. And we’ll use Amazon SQS (Simple Queue Service) for a simple task queue.

Replica Set

The high-availability version of MongoDB is called a Replica Set (Figure 7-1). In short, this is a collection of nodes, some of which hold data (members), and of those nodes holding data, one is master. The group uses a voting process to determine the master if there isn’t one or if the current one is not healthy anymore. Nondata member nodes are called arbiters.

MongDB Replica Set

Figure 7-1. MongDB Replica Set

A Replica Set is only operational if the majority is up. For instance, if you have three Availability Zones, you need at least three nodes: two members holding data and one arbiter. Keep in mind that if you lose an entire Availability Zone, you want to keep an operational Replica Set.

Set configuration

We are lucky that elections are part of MongoDB. ...

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, interactive tutorials, and more.

Start Free Trial

No credit card required