This document discusses advanced replication in MongoDB replica sets. It begins by explaining the roles and configuration of replica set members, including primaries, secondaries, and arbiters. It then covers the implementation details of replication using an oplog and heartbeats between nodes. The rest of the document discusses best practices for maintenance, data center awareness using tagging, write concerns, and read preferences to control data distribution and failover.
8. Implementation details
• Heartbeat every 2 seconds
– Times out in 10 seconds
• Local DB (not replicated)
– system.replset
– oplog.rs
• Capped collection
• Idempotent version of operation stored
14. Maintenance and Upgrade
• No downtime
• Rolling upgrade/maintenance
– Start with Secondary
– Primary last
– Commands:
• rs.stepDown(<secs>)
• db.version()
• db.serverBuildInfo()
16. Replica Set – 1 Data Center
• Single datacenter
Datacenter
• Single switch & power
Member 1 • Points of failure:
– Power
Member 2 – Network
– Data center
Datacenter 2
Member 3 – Two node failure
• Automatic recovery of
single node crash
17. Replica Set – 2 Data Centers
• Multi data center
Datacenter 1
• DR node for safety
Member 1
• Can’t do multi data
Member 2 center durable write
safely since only 1 node
in distant DC
Datacenter 2
Member 3
18. Replica Set – 2 Data Centers
• Analytics
• Disaster Recovery
• Batch Jobs
• Options
– low or zero priority
– hidden
– slaveDelay
19. Replica Set – 3 Data Centers
Datacenter 1 • Three data centers
Member 1
Member 2
• Can survive full data
center loss
Datacenter 2
Member 3 • Can do w= { dc : 2 } to
Member 4 guarantee write in 2
data centers (with tags)
Datacenter 3
Member 5
20. Replica Set – 3+ Data Centers
Secondary
Primary
Secondary
Secondary
Secondary delayed
Secondary
Secondary
28. Datacenter awareness (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
32. 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)
33. Tagged Read Preference
• Custom read preferences
• Control where you read from by (node) tags
– E.g. { "disk": "ssd", "use": "reporting" }
• Use in conjunction with standard read preferences
– Except primary
39. Best practices and tips
• Odd number of set members
• Read from the primary except for
– Geographically distribution
– Analytics (separate workload)
• Use logical names not IP Addresses in configs
• Set WriteConcern appropriately for what you are
doing
• Monitor secondaries for lag (Alerts in MMS)