29
MongoDB Replication Fundamentals Desert Code Camp – Oct 2014 By Avinash Ramineni [email protected]

MongoDB Replication fundamentals - Desert Code Camp - October 2014

Embed Size (px)

Citation preview

Page 1: MongoDB Replication fundamentals - Desert Code Camp - October 2014

MongoDB Replication Fundamentals

Desert Code Camp – Oct 2014By

Avinash [email protected]

Page 2: MongoDB Replication fundamentals - Desert Code Camp - October 2014

Agenda

• Introduction to MongoDB• MongoDB Replication• Understanding Oplog• Stream data from Oplog• Demo• Gotchas• Questions

Page 3: MongoDB Replication fundamentals - Desert Code Camp - October 2014

Why use a NoSQL Database?

• NoSQL describes a horizontally scalable, non-relational database with built-in replication support

• One Size does not Fit All– RDBMS

• Horizontal or Vertical Scalability ?– Key-Value stores– Column– Document and Graph

• High Availability and Scalability• CAP Theorem

– Choose any two from (Consistency, Availability , Partition Tolerance)• Availability and Partition Tolerance

Page 4: MongoDB Replication fundamentals - Desert Code Camp - October 2014

Why use a NoSQL Database? -2 • NoSQL’s primary goal is to achieve horizontal scalability. It attains

this by reducing transactional semantics and referential integrity.

Page 5: MongoDB Replication fundamentals - Desert Code Camp - October 2014

MongoDB -1

• Document Oriented Database– Bridges the gap between RDBMS and Key-Value Stores– Atomicity– Indexing– Sharding - horizontal Scalability

• BSON format– Binary encoded JSON representation

• No Joins• Complex Queries /Indices• Row Level Locking

Page 6: MongoDB Replication fundamentals - Desert Code Camp - October 2014

MongoDB -2

• MongoDB Cluster– Master - Slave• Slave can become Master incase of fail-over• Only Master is allowed to commit changes to Store

– Master – Master in limited capacity• Inserts/Queries/Deletions are done by Id• Does not work if the usecase expects same object can

be updated concurrently – ReplicaSets

Page 7: MongoDB Replication fundamentals - Desert Code Camp - October 2014

MongoDB -2

Page 8: MongoDB Replication fundamentals - Desert Code Camp - October 2014

Replication

• Why Replication ?– Failover Scenarios

• Hot Backups– Disaster Recovery

• Provides Redundancy and Increases Data Availability• Increases Read Capacity• Different uses of data

• Normal processing• DR / Backup• Reporting

Page 9: MongoDB Replication fundamentals - Desert Code Camp - October 2014

MongoDB Terminology

• Database – Collection (RDBMS – table)– Document (RDBMS – row)

• Cluster Node Types– Primary– Secondary– Arbiter– Hidden

Page 10: MongoDB Replication fundamentals - Desert Code Camp - October 2014

MongoDB Replication

Page 11: MongoDB Replication fundamentals - Desert Code Camp - October 2014

Replicasets

• Primary– Primary accepts all write operations– Only one Primary– Strict Consistency for reads– Logs all the changes in data to “oplog “

• Secondary– Replicate by reading Primary’s “oplog”– Reads might return stale data – Can become primary

Page 12: MongoDB Replication fundamentals - Desert Code Camp - October 2014

Cluster

Page 13: MongoDB Replication fundamentals - Desert Code Camp - October 2014

Primary Election

Page 14: MongoDB Replication fundamentals - Desert Code Camp - October 2014

Read Preference• Routes Read operations to Replica set Members• Increase Read throughputs• Reduce Latency • Secondary reads might be stale• Modes– Primary– Primary Preferred (secondary if primary unavailable)– Secondary– Secondary Preferred– Nearest (read from member with least network latency)

Page 15: MongoDB Replication fundamentals - Desert Code Camp - October 2014

Write Preference

• Write only on Primary (Default)• Write to N number of replica set members

db.products.insert( { item: "envelopes", qty : 100, type: "Clasp" }, { writeConcern: { w: 2, wtimeout: 5000 } })

Page 16: MongoDB Replication fundamentals - Desert Code Camp - October 2014

WriteConcern: Unacknowledged

Page 17: MongoDB Replication fundamentals - Desert Code Camp - October 2014

WriteConcern: Acknowledged

Page 18: MongoDB Replication fundamentals - Desert Code Camp - October 2014

WriteConcern: Journaled

Page 19: MongoDB Replication fundamentals - Desert Code Camp - October 2014

WriteConcern w:2

Page 20: MongoDB Replication fundamentals - Desert Code Camp - October 2014

Stream data from MongoDB

Page 21: MongoDB Replication fundamentals - Desert Code Camp - October 2014

Oplog (Operation Log)

• Similar to Oracle Redo log– Rolling record of all operations that modify the

data – All writes (insert/update/delete) get an entry in

the Oplog• Replicaset members have oplog collection– local.oplog.rs– Oplog is yet another collection in the database

Page 22: MongoDB Replication fundamentals - Desert Code Camp - October 2014

Oplog in Action - Demo

Page 23: MongoDB Replication fundamentals - Desert Code Camp - October 2014

Dissecting Oplog

Page 24: MongoDB Replication fundamentals - Desert Code Camp - October 2014

Dissecting Oplog ..

• Oplog Contents– ts: the time this operation occurred.– h: a unique ID for this operation. Each operation will

have a different value in this field.– op: the write operation that should be applied to the

slave – ns: the database and collection affected by this

operation.– o: the actual document representing the operation– v: Version of the oplog.

Page 25: MongoDB Replication fundamentals - Desert Code Camp - October 2014

Oplog - op

• Op – Operation– i inserts– u updates– d deletes– n no-op

• Updates has an extra field– o2• o1 has update information• o2 has the id that was updated

Page 26: MongoDB Replication fundamentals - Desert Code Camp - October 2014

Triggers?

• Does mongoDB have triggers?– Tailable cursors• tail –f oplog

• Notice any issues with oplog– Aren't we doubling the size of the database ?

Page 27: MongoDB Replication fundamentals - Desert Code Camp - October 2014

Oplog ..

• Capped Collection (fixed Size collection)– Circular Queue– Default Oplog size depends on the OS– Oldest entries get overwritten

• What if the slave node is way off that the oplog got overwritten– Full Resync

• copyDatabase starts streaming from oplog– What if oplog rolls over while the slaves are completing

the copy

Page 28: MongoDB Replication fundamentals - Desert Code Camp - October 2014

Non-Replicated Collections

• local database– Collections in local don’t get replicated– Changes to the collections in local database don’t

show up in the oplog

Page 29: MongoDB Replication fundamentals - Desert Code Camp - October 2014

Questions