Replication and Replica Sets

438 views

Published on

For the first time this year, 10gen will be offering a track completely dedicated to Operations at MongoSV, 10gen's annual MongoDB user conference on December 4. Learn more at MongoSV.com

Sharding allows you to distribute load across multiple servers and keep your data balanced across those servers. This session will review MongoDB’s sharding support, including an architectural overview, design principles, and automation.

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
438
On SlideShare
0
From Embeds
0
Number of Embeds
52
Actions
Shares
0
Downloads
9
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Replication and Replica Sets

  1. 1. Sridhar Nanjundeswaran, 10gen sridhar@10gen.com @snanjund October 21, 2012 1
  2. 2. • Introduction to Replica Sets• Developing with Replica Sets• Operational Considerations• Miscellaneous 2
  3. 3. Introduction to Replica Sets Why? What is it? Configuration Options
  4. 4. • How many have faced node failures?• How many have been woken to do fail overs?• How many have experienced issues due to n/w latency?• Different uses for data – Normal processing – Simple analytics 4
  5. 5. Node 1 Node 2 Node 3 5
  6. 6. Node 1 Node 2Secondary Heartbeat Secondary Node 3 Primary Replication Replication 6
  7. 7. Primary Election Node 1 Node 2Secondary Heartbeat Secondary Node 3 Primary 7
  8. 8. Replication Node 1 Node 2Secondary Heartbeat Primary Node 3 Primary 8
  9. 9. Replication Node 1 Node 2Secondary Heartbeat Primary Node 3 Secondary Replication 9
  10. 10. Node 1 Node 2Secondary Heartbeat Arbiterr Node 3 Primary Replication 10
  11. 11. > 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) 11
  12. 12. > conf = { _id : "mySet”, Primary DC 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) 12
  13. 13. > conf = { _id : "mySet”, members : [ {_id : 0, host : "A”, priority : 3}, {_id : 1, host : "B", priority : 2}, Secondary DC {_id : 2, host : "C”}, Default priority = 1 {_id : 3, host : "D", hidden : true}, {_id : 4, host : "E", hidden : true, slaveDelay : 3600} ]}> rs.initiate(conf) 13
  14. 14. > conf = { _id : "mySet”, Analytics node 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
  15. 15. > 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} ]} Backup node> rs.initiate(conf) 15
  16. 16. Developing with Replica Sets Consistency Write Preference Read Preference
  17. 17. Write DriverClient Primary Read Secondary Secondary 17
  18. 18. WriteClient Application Primary Driver Secondary Read Secondary Read 18
  19. 19. • Fire and forget• Wait for error• Wait for journal sync• Wait for replication 19
  20. 20. Driver Primary write apply in memory 20
  21. 21. Driver Primary getLastError apply in memory 21
  22. 22. Driver Primary write getLastError apply in memory j:true Write to journal 22
  23. 23. Driver Primary Secondary write getLastError apply in memory W:majority replicate 23
  24. 24. • Since 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 changing app code 24
  25. 25. { _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"}) 25
  26. 26. Driver Primary (sf) Secondary (ny) Secondary write (cloud) getLastError apply in memory W:allDCs replicate replicate 26
  27. 27. • 5 modes (new in 2.2) – primary (only) - Default – primaryPreferred – secondary – secondaryPreferred – nearest 27
  28. 28. • Custom read preferences• Control where you read from – E.g. { "disk": "ssd", "use": "reporting" }• Use in conjunction with standard read preferences – Except primary 28
  29. 29. Operational Considerations Upgrade/Maintenance Common Deployment Scenarios
  30. 30. • No downtime• Rolling upgrade/maintenance – Start with Secondary – Primary last 30
  31. 31. • Single datacenter • Single switch & powerMember 1 • Points of failure: – PowerMember 2 – Network – DatacenterMember 3 – Two node failure • Automatic recovery of single node crash 31
  32. 32. • Multi datacenterDC Member 1 • DR node for safety1 • Can’t do multi data Member 2 center durable write safely since only 1 node in distant DCDC Member 32 32
  33. 33. • Three data centersDC • Can survive full data Member 11 center loss Member 2 • Can do w= { dc : 2 } to guarantee write in 2DC Member 32 data centers (with Member 4 tags)DC Member 5 -3 DR 33
  34. 34. Behind the Curtain Schema Oplog
  35. 35. • Heartbeat every 2 seconds – Times out in 10 seconds• Local DB (not replicated) – system.replset – oplog.rs • Capped collection • Idempotent version of operation stored 35
  36. 36. > db.replsettest.insert({_id:1,value:1}){ "ts" : Timestamp(1350539727000, 1), "h" :NumberLong("6375186941486301201"), "op" : "i", "ns" :"test.replsettest", "o" : { "_id" : 1, "value" : 1 } }> db.replsettest.update({_id:1},{$inc:{value:10}}){ "ts" : Timestamp(1350539786000, 1), "h" :NumberLong("5484673652472424968"), "op" : "u", "ns" :"test.replsettest", "o2" : { "_id" : 1 }, "o" : { "$set" : { "value" :11 } } } 36
  37. 37. > db.replsettest.update({},{$set:{name : ”foo”}, false, true}){ "ts" : Timestamp(1350540395000, 1), "h" : NumberLong("-4727576249368135876"), "op" : "u", "ns" : "test.replsettest", "o2" : {"_id" : 2 }, "o" : { "$set" : { "name" : "foo" } } }{ "ts" : Timestamp(1350540395000, 2), "h" : NumberLong("-7292949613259260138"), "op" : "u", "ns" : "test.replsettest", "o2" : {"_id" : 3 }, "o" : { "$set" : { "name" : "foo" } } }{ "ts" : Timestamp(1350540395000, 3), "h" : NumberLong("-1888768148831990635"), "op" : "u", "ns" : "test.replsettest", "o2" : {"_id" : 1 }, "o" : { "$set" : { "name" : "foo" } } } 37
  38. 38. • Use replica sets• Easy to setup – Try on a single machine• Check doc page for RS tutorials – http://docs.mongodb.org/manual/replication/#t utorials 38
  39. 39. download at mongodb.org We’re Hiring ! sridhar@10gen.com @snanjund conferences, appearances, and meetups http://www.10gen.com/events Facebook | Twitter | LinkedIn http://bit.ly/mongofb @mongodb http://linkd.in/joinmongo© Copyright 2010 10gen Inc. 39

×