• Like

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Webinar: Replication and Replica Sets

  • 2,048 views
Published

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 …

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.

Published in Technology , Business
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
2,048
On SlideShare
0
From Embeds
0
Number of Embeds
6

Actions

Shares
Downloads
110
Comments
0
Likes
5

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • 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?
  • Schemaoplog

Transcript

  • 1. Introduction to Replication and Replica Sets Rohit Nijhawan Consulting Engineer, MongoDB
  • 2. Agenda • Replica Sets Lifecycle • Developing with Replica Sets • Operational Considerations
  • 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
  • 4. Replica Set Lifecycle
  • 5. Replica Set – Creation
  • 6. Replica Set – Initialize
  • 7. Replica Set – Failure
  • 8. Replica Set – Failover
  • 9. Replica Set – Recovery
  • 10. Replica Set – Recovered
  • 11. Replica Set Roles & Configuration
  • 12. Replica Set Roles
  • 13. Configuration Options > conf = { _id : "mySet", members : [ {_id : 0, host : "A”, priority : 3}, {_id : 1, host : "B", priority : 2}, {_id : 2, host : "C”}, {_id : 3, host : "D", hidden : true}, {_id : 4, host : "E", hidden : true, slaveDelay : 3600} ] } > rs.initiate(conf)
  • 14. Configuration Options > conf = { _id : "mySet”, members : [ Primary DC {_id : 0, host : "A”, priority : 3}, {_id : 1, host : "B", priority : 2}, {_id : 2, host : "C”}, {_id : 3, host : "D", hidden : true}, {_id : 4, host : "E", hidden : true, slaveDelay : 3600} ] } > rs.initiate(conf)
  • 15. Configuration Options > conf = { _id : "mySet”, members : [ Secondary DC Default Priority = 1 {_id : 0, host : "A”, priority : 3}, {_id : 1, host : "B", priority : 2}, {_id : 2, host : "C”}, {_id : 3, host : "D", hidden : true}, {_id : 4, host : "E", hidden : true, slaveDelay : 3600} ] } > rs.initiate(conf)
  • 16. Configuration Options > conf = { _id : "mySet”, members : [ {_id : 0, host : "A”, priority : 3}, {_id : 1, host : "B", priority : 2}, {_id : 2, host : "C”}, {_id : 3, host : "D", hidden : true}, {_id : 4, host : "E", hidden : true, slaveDelay : 3600} ] } > rs.initiate(conf) Analytics node
  • 17. Configuration Options > conf = { _id : "mySet”, members : [ {_id : 0, host : "A”, priority : 3}, {_id : 1, host : "B", priority : 2}, {_id : 2, host : "C”}, {_id : 3, host : "D", hidden : true}, {_id : 4, host : "E", hidden : true, slaveDelay : 3600} ] } > rs.initiate(conf) Backup node
  • 18. Developing with Replica Sets
  • 19. Strong Consistency
  • 20. Delayed Consistency
  • 21. Write Concern • Network acknowledgement • Wait for error • Wait for journal sync • Wait for replication
  • 22. Unacknowledged
  • 23. MongoDB Acknowledged (wait for error)
  • 24. Wait for Journal Sync
  • 25. Wait for Replication
  • 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
  • 27. 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 : "someDCs"})
  • 28. Wait for Replication (Tagging)
  • 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)
  • 30. Operational Considerations
  • 31. Maintenance and Upgrade • No downtime • Rolling upgrade/maintenance – Start with Secondary – Primary last
  • 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
  • 37. Questions?
  • 38. Thank You Rohit Nijhawan Consulting Engineer, MongoDB