Search
Follow Us

Follow nosqldatabases on Twitter Follow nosqldatabases on Facebook Follow nosqldatabases on Google Buzz Follow nosqldatabases on LinkedIn Follow nosqldatabases on FeedBurner NoSQL presentations on slideshare

Sponsors

Become a sponsor of NoSQLDatabases.com. Contact us to find out how.

Featured Jobs

 

Follow On Facebook
Recent NoSQL News

Advertisments

Entries in Replica Sets (3)

Friday
Nov122010

Scaling with MongoDB

Here is the video from Kristina Chodorow's O'Reilly webcast Scaling with MongoDB. The webcast focused on MongoDB's sharding functionality and how it allows MongoDB to scale horizontally. In addition, the webcast focused on replica sets and how they enable automatic failover and recovery of database nodes.

Click to read more ...

Tuesday
Sep142010

Scaling with MongoDB Webcast

Kristina Chodorow, software engineer at 10gen, will be discussing how to scale with MongoDB this Friday (9/17) at 10am PST.

Full description of the webcast:

MongoDB's architecture features built-in support for horizontal scalability, and high availability through replica sets. Auto-sharding allows users to easily distribute data across many nodes. Replica sets enable automatic failover and recovery of database nodes within or across data centers. This webcast will provide an introduction to scaling with MongoDB by one of the developers working on the project.

For those who need reminders follow us on Twitter or Facebook, we'll send out a reminder on Friday morning 6am PST.

Sign up for the webcast here: Scaling with MongoDB

Tuesday
Aug242010

Replica Sets with MongoDB

MongoDB recently released version 1.6, one of the key features of that release, replica sets. In this presentation, by Dwight Merriman he discusses replica sets, specifically the basics, design, etc.

What makes a replica set?

  • A cluster of N servers
  • Any (one) node can be primary
  • Consensus election of primary
  • Automatic failover
  • Automatic recovery
  • All writes to primary 
  • Reads can be to primary (default) or a secondary 

Key Design Concepts:

  1. A write is only truly committed once it has replicated to a majority of servers in the set. Thus, for important writes, the developer waits for confirmation of the cluster-wide commit with the getLastError command.
  2. Writes which are committed at the master of the set may be visible before the true cluster-wide commit has occurred.  This property, which is more relaxed than some traditional products, makes theoretically achievable performance and availability higher.
  3. On a failover, if there is data which has not replicated form the primary, the data is dropped (see #1).

Check out the entire presentation below: