ALL COVERED TOPICS

NoSQL Benchmarks NoSQL use cases NoSQL Videos NoSQL Hybrid Solutions NoSQL Presentations Big Data Hadoop MapReduce Pig Hive Flume Oozie Sqoop HDFS ZooKeeper Cascading Cascalog BigTable Cassandra HBase Hypertable Couchbase CouchDB MongoDB OrientDB RavenDB Jackrabbit Terrastore Amazon DynamoDB Redis Riak Project Voldemort Tokyo Cabinet Kyoto Cabinet memcached Amazon SimpleDB Datomic MemcacheDB M/DB GT.M Amazon Dynamo Dynomite Mnesia Yahoo! PNUTS/Sherpa Neo4j InfoGrid Sones GraphDB InfiniteGraph AllegroGraph MarkLogic Clustrix CouchDB Case Studies MongoDB Case Studies NoSQL at Adobe NoSQL at Facebook NoSQL at Twitter

NAVIGATE MAIN CATEGORIES

Close

MongoDB Replica Sets

Even if MongoDB replica sets ☞ official documentation is quite good, that doesn’t mean more coverage of the subject is not going to be useful. So, this is kind of everything you need to read about MongoDB replica sets.

Let’s start with Kristina Chodorow’s series on MongoDB replica sets:

  • ☞ Replica sets part1: Master-Slave is so 2009

    This post shows how to do the “Hello, world” of replica sets. I was going to start with a post explaining what they are, but coding is more fun than reading. For now, all you have to know is that they’re master-slave with automatic failover.

  • ☞ Replica sets part2: what are replica sets

    Replica sets are basically just master-slave with automatic failover.

    So, you have a pool of servers with one primary (the master) and N secondaries (slaves). If the primary crashes or disappears, the other servers will hold an election to choose a new primary.

  • ☞ Part 3: Replica sets in the wild:

    […] you might want to migrate dev servers into production, add new slaves, prioritize servers, change things on the fly… that’s what this post covers.

  • ☞ Sharding and replica sets illustrated:

    Let’s say we drop a tray. CRASH! With this setup, your data is safe (as long as you were using w) and the cluster loses no functionality (in terms of reads and writes).

    Chunks will not be able to migrate (because one of the config servers is down), so a shard may become bloated if the config server is down for a very long time.

    Network partitions and losing two server are bigger problems, so you should have more than three servers if you actually want great availability.

If Kristina’s first post covered MongoDB replica sets setup, BoxedIce guys ☞ have also a post on the topic:

You can have any number of members in a replica set and your data will exist in full on each member of the set. This allows you to have servers distributed across data centres and geographies to ensure full redundancy. One server is aways the primary to which reads and writes are sent, with the other members being secondary and accepting reads only. In the event of the primary failing, another member will take over automatically.

plus a video showing the setup:

And nothing is complete without videos, so here is Dwight Merriman’s talk on MongoDB replication and replica sets:

Last, but not least you can find a replica sets demo video on ☞ 10gen blog.

Original title and link: MongoDB Replica Sets (NoSQL databases © myNoSQL)