Replication and Replica Sets - Tony Hannan, Software Engineer, 10gen

MongoDallas 2011

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 show you how to set up, configure, and initiate a replica set, and methods for using replication to scale reads. We'll also discuss proper architecture for durability.

Transcript

1. Replication in MongoDB by Tony Hannan tony@10gen.com MongoDallas, Nov 2011
2. Data Replication Advantages – Fault-tolerance – Scalability of reads But how do we keep the replicas in sync (consistent)?
3. Synchronous Replication models, two dimensions Asynchronous Mul ti m as t er Mas t er s l ave Two-phase commit Two-phase commit Conflict reconciliation
4. Properties Synchronous Master-slave Synchronous Multi-master Asynchronous Master-slave Asynchronous Multi-master Conflicts None None None Application reconciliation Consistency – Read Strict – master or quorum, Eventual – any Strict – quorum, Eventual – any Strict – master, Eventual – any Eventual – any Write Quorum round trip + master could be far away Quorum round trip Immediate but master could be far away Immediate Failover All writers halt while failure detected & new master elected Afected writers instantly switch replica, others unafected Latest updates lost. All writers halt while failure detected & new master elected Some latest updates lost. Afected writers instantly switch replica, others unafected Network Partition Minority half can’t write Minority half can’t write Minority half can’t write Both halves available but diverge
5. Hybrid models and variations • Master-slave per document (disjoint multi-master) • Synchronous core servers with asynchronous slaves • Choose asynchronous or synchronous replication on each write • Optional, non-atomic synchronous replication* – Less costly than two-phase commit – Guaranteed redundancy on completion – But can’t guarantee no-op on failure • Optional, asynchronous write* – No acknowledgement (not even from master) – Failures ignored (e.g. duplicate key) – Very fast * In MongoDB
6. Custom redundancy in MongoDB • On (non-atomic) synchronous replication, you can be more specifc about where you want the updates to be guaranteed to go • R1 tags {dc: ny} • R2 tags {dc: ny} • R3 tags {dc: sf} • R4 tags {dc: sf} – db.foo.insert(Doc) – db.getLastError({w: {dc: 2}, timeout: 3 secs}) or – db.getLastError({w: “majority”, timeout: 3 secs})
7. Async master-slave R1 Master u1, u2, u3, u4 R2 Slave u1, u2 R3 Slave u1
8. Async master-slave Failover network partition R1 Master u1, u2, u3, u4 Slave R2 Slave u1, u2 Master R3 Slave u1
9. Async master-slave network partition R1 Slave u1, u2, u3, u4 R2 Master u1, u2, u5, u6, u7 R3 Slave u1, u2, u5, u6
10. Async master-slave Recovery R1 Slave u1, u2, u3, u4 Recovering u1, u2, u5, u6, u7 Slave R2 Master u1, u2, u5, u6, u7 R3 Slave u1, u2, u5, u6 u3, u4
11. Replica set confguration • Start processes with --replicaSet option host1$ mongod --replSet rsA host2$ mongod --replSet rsA host3$ mongod –replSet rsA • From shell connect to host1 and confgure > rs.initiate() > rs.add(“host2”) > rs.add(“host3”) > rs.status() • Access replica set from client driver c = connect(“rsA/host1,host2”) db = c.getDB(“db”) db.foo.fnd() db.setSlaveOk() db.foo.fnd()
12. Data Partitioning in MongoDB