Practical Replication June-2011
0 likes397 views
Replication in MongoDB allows for high availability and scaling of reads. A replica set consists of at least three mongod servers, with one primary and one or more secondaries that replicate from the primary. The primary applies all write operations to its oplog, which is then replicated to the secondaries. If the primary fails, a new primary is elected from the remaining secondaries. Administrative commands help monitor and manage the replica set configuration.
More Related Content
What's hot (20)
Viewers also liked (8)
Similar to Practical Replication June-2011 (20)
![Cloud init and cloud provisioning [openstack summit vancouver]](https://cdn.slidesharecdn.com/ss_thumbnails/cloud-initandcloudprovisioningopenstacksummitvancouverwip-160517225244-thumbnail.jpg?width=560&fit=bounds)
More from Chris Westin (17)
Recently uploaded (20)
Practical Replication June-2011
- 1. Practical ReplicationChris WestinSoftware Engineer, 10gen© Copyright 2010 10gen Inc.
- 2. What is Replication for?High availabilityIf a node fails, another node can step inExtra copies of data for recoveryScaling readsApplications with high read rates can read from replicas
- 3. What Does Replication Look Like?Replica SetA set of mongod serversMinimum of 3Can use “arbiters”Consensus election of a “primary”All writes go to primary“Secondaries” replicate from primary
- 4. Configuring a Replica SetStart mongod processes with --replSet <name>Then:
- 5. Managing a Replica Set--oplogSize <MB>mongod option: choose size of replication log--fastsyncmongod option: skip full resync of new secondary that was created from a recent copyrs.add(“hostname:<port>”)Shell helper: add a new memberrs.remove(“hostname:<port>”)Shell helper: remove a member
- 6. Some Administrative CommandsreplSetGetStatusReports status of the replica set from one node’s point of viewreplSetStepDownRequest the primary to step downreplSetFreezePrevents any changes to the current replica set configuration (primary/secondary status)Use during backups
- 7. How Does it Work?Change operations are written to the oplogThe oplog is a capped collectionMust have enough space to allow new secondaries to catch up after copying from a primaryMust have enough space to cope with any applicable slaveDelaySecondaries query the primary’s oplog and apply what they find
- 8. FailoverReplica set members monitor each other via heartbeatsIf the primary can’t be reached, a new one is electedThe secondary with the most up-to-date oplog is chosenIf, after election, a secondary has changes not on the new primary, those are undone, and moved aside (changes saved to a BSON file)If you require a guarantee, ensure data is written to a majority of the replica set
- 9. PriorityOptional parameter to replica set member configurationAll other things being equal, the highest priority member wins the election for primaryChanges in secondaries’ relative lag, i.e., catching up to primary, can trigger an electionZero priority: can never become primaryUse for remote DR, delayed slaves, backups, analytics sources
- 10. For ApplicationsgetLastError( { w : … } )Application waits until changes are written to the specified number of serversDefaults can be set in the replica set’s configuration“Safe mode” for critical writes: setWriteConcern()Another way to force writes to a number of serversDrivers support “slaveOk” for sending queries to a secondaryThis is for scaling reads
- 11. Replication and ShardingEach shard needs its own replica setDrivers use a mongos process to route queries to the appropriate shard(s)Configuration servers maintain the shard key range metadata
- 13. Data Center AwarenessTag nodes in replica set configurationApply hierarchical labels to replica set membersDefine getLastError modesRequire number of nodes writes must go toRequire locations of nodes writes must go toCombinationsAvailable in 1.9.1
- 14. Tagging Example