MongoDB supports replication for failover and redundancy. In this session we will introduce the basic concepts around replica sets, which provide automated failover and recovery of nodes. We'll cover how to set up, configure, and initiate a replica set; methods for using replication to scale reads; and proper architecture for durability.
3. Why Replication?
• How many have faced node failures?
• How many have been woken up from sleep to do a
fail-over(s)?
• How many have experienced issues due to network
latency?
• Different uses for data
– Normal processing
– Simple analytics
26. Tagging
•
Control where data is written to, and read from
•
Each member can have one or more tags
– tags: {dc: "ny"}
– tags: {dc: "ny",
subnet: "192.168",
rack:
"row3rk7"}
•
Replica set defines rules for write concerns
•
Rules can change without changing app code
29. Read Preference Modes
•
5 modes
–
–
–
–
–
primary (only) - Default
primaryPreferred
secondary
secondaryPreferred
Nearest
When more than one node is possible, closest node is used
for reads (all modes but primary)
32. Replica Set – 1 Data Center
Single datacenter
Single switch & power
Points of failure:
–
–
–
–
Power
Network
Data center
Two node failure
Automatic recovery of
single node crash
33. Replica Set – 2 Data Centers
Multi data center
DR node for safety
Can’t do multi data
center durable write
safely since only 1 node
in distant DC
34. Replica Set – 3 Data Centers
Three data centers
Can survive full data
center loss
Can do w= { dc : 2 } to
guarantee write in 2 data
centers (with tags)
35. Recent improvements
Read preference support with sharding
– Drivers too
Improved replication over WAN/high-latency
networks
rs.syncFrom command
buildIndexes setting
replIndexPrefetch setting
36. Just Use It
Use replica sets
Easy to setup
– Try on a single machine
Check doc page for RS tutorials
– http://docs.mongodb.org/manual/replication/#tutorials
Basic explanation2 or more nodes form the setQuorum
Initialize -> ElectionPrimary + data replication from primary to secondary
Primary down/network failureAutomatic election of new primary if majority exists
New primary electedReplication established from new primary
Down node comes upRejoins setsRecovery and then secondary
PrimaryData memberSecondaryHot standbyArbitersVoting member
PriorityFloating point number between 0..1000Highest member that is up to date wins Up to date == within 10 seconds of primaryIf a higher priority member catches up, it will force election and win Slave DelayLags behind master by configurable time delay Automatically hidden from clientsProtects against operator errorsFat fingeringApplication corrupts data
PriorityFloating point number between 0..1000Highest member that is up to date wins Up to date == within 10 seconds of primaryIf a higher priority member catches up, it will force election and win Slave DelayLags behind master by configurable time delay Automatically hidden from clientsProtects against operator errorsFat fingeringApplication corrupts data
PriorityFloating point number between 0..1000Highest member that is up to date wins Up to date == within 10 seconds of primaryIf a higher priority member catches up, it will force election and win Slave DelayLags behind master by configurable time delay Automatically hidden from clientsProtects against operator errorsFat fingeringApplication corrupts data
Analytics good for integrations with Hadoop, Storm, etc.
PriorityFloating point number between 0..1000Highest member that is up to date wins Up to date == within 10 seconds of primaryIf a higher priority member catches up, it will force election and win Slave DelayLags behind master by configurable time delay Automatically hidden from clientsProtects against operator errorsFat fingeringApplication corrupts data
ConsistencyWrite preferencesRead preferences
Not really fire and forget. This return arrow is to confirm that the network successfully transferred the packet(s) of data.This confirms that the TCP ACK response was received.
Presenter should mention:Default is w:1w:majority is what most people should use for durability. Majority is a special token here signifying more than half of the nodes in the set have acknowledged the write.
Using 'someDCs' so that in the event of an outage, at least a majority of the DCs would receive the change. This favors availability over durability.
Using 'allDCs' because we want to make certain all DCs have this piece of data. If any of the DCs are down, this would timeout. This favors durability over availability.
Upgrade/maintenanceCommon deployment scenarios
A good question to ask the audience : 'Why wouldn't you set w={dc:3}'… Why would you ever do that? What would be the complications?