managing a mongodb deployment
Post on 11-May-2015
5.685 Views
Preview:
DESCRIPTION
TRANSCRIPT
MANAGING A MONGODB DEPLOYMENT
Tony Tam @fehguy
AREAS OF DISCUSSION
Many drivers to go non-relationalMaybe you already are?SOA?
“Yes we should!” Now what? Implementation details, best practices
Depends on what system you chooseOperational Architecture
Making your deployment “maintainable”Maximizing performance
Software + Hardware tuning
WORDNIK SAYS YES TO MONGODB
And we’re alive to talk about itOur stats
14 M REST API calls yesterday7 ms avg. response3 TB of MongoDB dataMostly all “un-cached” responses
SOFTWARE ARCHITECTURE
Java/Scala/Jetty application serversShare (almost) nothingAll roads in must speak REST
DEPLOYMENT ARCHITECTURE
Wordnik uses physical servers
OPERATIONAL CONSTRAINTS
Fundamental question to answerCan we support this?
You need to considerIf you want it to scaleIf you have a SLA to supportIf you carry the pager
Also important ifYou have customersYou like your job
OPERATIONAL CONSTRAINTS
Core items for WordnikRedundancy with master/slave
Multi-datacenter deployment possible?Design for read-only mode
Control at the driver levelBlocking
When is it OK?Steps around with MongoDB
ConsistencyWhen does it matter?
Scale-outWhat limits our speed/size?
Other?Some features => opportunity
REDUNDANCY
MongoDB supports MS and Replica SetsRS is like MS with auto-failoverDriver intelligenceStill one master, elected by peers
Master
Slave
Slave
Slave
Master
Slave
Slave
Master
Slave
Slave
Slave
REDUNDANCY
Master/Slave fine for us but…Not fine for multi operational datacenters
resync?Your data drives the appropriate solutionCustom tools to support thishttps://github.com/wordnik/wordnik-oss
SCP
Primary Datacenter
Master
Incremental Backup
Files
Hot Datacenter
Master
Replay Util
REDUNDANCY
Multi-datacenter deploymentSome data need not be consistent
Some doesReplication tricks for master-master
Master 1 Master 2
db.documentsdocuments.src == 1
db.documentsdocuments.src == 2
CONTROLLING BLOCKING OPERATIONS
Important to know what blocksSome situations can create global locks
Know what happens with:Adding dataDeleting dataModifying data
…Then toss in 100 reads/secOnly access your DB “the right way”
Enforce by good software designThe right way == “right way for your db”
CONTROLLING BLOCKING OPERATIONS
Wordnik SolutionMongoDB access via service layer
Only allow queries you want runAll others => non-production server,
HadoopSmart driver manager
Slave bias $inc:{page_views:1} => $set{page_views:10038}
Read-only modeHot-remove server from pool
HANDLING EVENTUAL CONSISTENCY
EC makes things fastMay create timing issuesSometimes need current data
val db:DB = getReadWriteConnection()
Avoid this a much as possibleBut if you must…
Write then call “getLastError”Forces commit to DB
RS allows “replicate to n nodes”Forces commit to master, n slaves
SCALE-OUT
What are you scaling?Size of dataSize of indexesOperations
Add slave serversWon’t help if size > index/server capacity
Sharding if done rightAutoshard solutionRoll your own
SCALE-OUT
Selecting a shard keyCan be trickyDepends on what you need
KEEPING IT RUNNING
BackupsExport with “mongodump”No incremental backup solution included
Wordnik tools https://github.com/wordnik/wordnik-oss
WORDNIK OSS TOOLS
Take our tools-They work!!!SnapshotUtil
Selectively snapshot in BSON Index info too!
IncrementalBackupUtilTail the oplog, stream to disk
Only the collections you want! Compress & rotate
RestoreUtilRecover your snapshots
Apply indexes yourself
ReplayUtilApply your Incremental backups
WHAT IF SCENARIOS
One collection gets corrupt?Restore itApply all operations to it
“My top developer dropped a collection!”Restore just that oneApply operations to it until that POT
“We got hacked!”Restore it allApply operations until that POT
WRAP UP: WE LIKE MONGODB
See more @ http://developer.wordnik.com
Questions?
top related