Replication

Alvin Richards - alvin@10gen.com

MongoDB Replication
MongoDB replication like MySQL replication

Asynchronous master/slave
Variations:

Master / slave Replica Sets

Replica Set features

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

How MongoDB Replication works

Member 1 Member 3

Member 2

Set is made up of 2 or more nodes

How MongoDB Replication works

Member 1 Member 3

Member 2 PRIMARY

Election establishes the PRIMARY Data replication from PRIMARY to SECONDARY

How MongoDB Replication works

Member 1 negotiate new master Member 3

Member 2 DOWN

PRIMARY may fail Automatic election of new PRIMARY if majority

exists

How MongoDB Replication works

Member 1

Member 3 PRIMARY

Member 2 DOWN

New PRIMARY elected Replication Set re-established

How MongoDB Replication works

Member 1

Member 3 PRIMARY

RECOVERING

Member 2

Automatic recovery

How MongoDB Replication works

Member 1

Member 3 PRIMARY

Member 2

Replication Set re-established

Creating a Replica Set

> cfg = { _id : "acme_a", members : [ { _id : 0, host : "sf1.acme.com" }, { _id : 1, host : "sf2.acme.com" }, { _id : 2, host : "sf3.acme.com" } ] } > use admin > db.runCommand( { replSetInitiate : cfg } )

Replica Set Options

{arbiterOnly: True} Can vote in an election Does not hold any data

{hidden: True}

Not reported in isMaster() Will not be sent slaveOk() reads

{priority: n} {tags: }

Priorities
Prior to 2.0.0
{priority:0} // Never can be elected Primary {priority:1} // Can be elected Primary

New in 2.0.0 Priority, floating point number between 0 and 1000 During an election Allows weighting of members during failover
Most up to date Highest priority

Priorities - example
Assuming all members are up to date Members A or B will be chosen first Highest priority Members C or D will be chosen next if A and B are unavailable A and B are not up to date Member E is never chosen priority:0 means it cannot be elected
A p:2 B p:2 C p:1 D p:1 E p:0

Tagging
New in 2.0.0 Control over where data is written to Each member can have one or more tags e.g. tags: {dc: "ny"} tags: {dc: "ny",
ip: "192.168", rack: "row3rk7"} Replica set defines rules for where data resides Rules can change without change application code

Tagging - example
{ _id : "mySet", members : [ {_id : 0, host : "A", tags : {"dc": "ny"}}, {_id : 1, host : "B", tags : {"dc": "ny"}}, {_id : 2, host : "C", tags : {"dc": "sf"}}, {_id : 3, host : "D", tags : {"dc": "sf"}}, {_id : 4, host : "E", tags : {"dc": "cloud"}}] settings : { getLastErrorModes : { allDCs : {"dc" : 3}, someDCs : {"dc" : 2}} } } > db.blogs.insert({...}) > db.runCommand({getLastError : 1, w : "allDCs"})

Using Replicas for Reads

slaveOk() - driver will send read requests to Secondaries - driver will always send writes to Primary Java examples - DB.slaveOk() - Collection.slaveOk()

- find(q).addOption(Bytes.QUERYOPTION_SLAVEOK);

Safe Writes
db.runCommand({getLastError: 1, w : 1})
- ensure write is synchronous - command returns after primary has written to memory

w=n or w='majority'

- n is the number of nodes data must be replicated to - driver will always send writes to Primary

w='myTag' [MongoDB 2.0]

- Each member is "tagged" e.g. "US_EAST", "EMEA", "US_WEST" - Ensure that the write is executed in each tagged "region"

Safe Writes
fsync:true
- Ensures changed disk blocks are ushed to disk

j:true

- Ensures changes are ush to Journal

When are elections triggered?

When a given member

See's that the Primary is not reachable The member is not an Arbiter Has a priority greater than other eligible members

Typical Deployments
Use? X Set size One Two Three X Four Data Protection No Yes Yes Yes High Availability Notes No No Yes - 1 failure Yes - 1 failure* Must use --journal to protect against crashes On loss of one member, surviving member is read only On loss of one member, surviving two members can elect a new primary * On loss of two members, surviving two members are read only On loss of two members, surviving three members can elect a new primary

Five

Yes

Yes - 2 failures

Use Cases - Multi Data Center

write to three data centers
allDCs : {"dc" : 3} > db.runCommand({getLastError : 1, w : "allDCs"})

write to two data centers and three availability zones

allDCsPlus : {"dc" : 2, "az": 3} > db.runCommand({getLastError : 1, w : "allDCsPlus"})
US-EAST-1 tag : {dc: "JFK", az: "r1"} US-EAST-2 tag : {dc: "JFK" az: "r2"} US-WEST-1 tag : {dc: "SFO", az : "r3"} US-WEST-2 tag : {dc: "SFO" az: "r4"} LONDON-1 tag : {dc: "LHR", az: "r5"}

Use Cases - Data Protection & High Availability

A and B will take priority during a failover C or D will become primary if A and B become unavailable E cannot be primary D and E cannot be read from with a slaveOk() D can use be used for Backups, feed Solr index etc. E provides a safe guard for operational or application error
A priority: 2 B priority: 2 C priority: 1 D priority: 1 hidden: True E priority: 0 hidden: True slaveDelay: 3600

Replication features
Reads from Primary are always consistent Reads from Secondaries are eventually consistent Automatic failover if a Primary fails Automatic recovery when a node joins the set Control of where writes occur

download at mongodb.org

Were Hiring !
alvin@10gen.com
conferences, appearances, and meetups
http://www.10gen.com/events

http://bit.ly/mongoN

Facebook | Twitter | LinkedIn

@mongodb

http://linkd.in/joinmongo