Serie Sviluppo di un’ApplicazioneBack to BasicsBackup & Disaster Recovery

Senior Solutions Architect, MongoDB Inc.

massimo@mongodb.com

Massimo Brignoli

#MongoDBBasics

Agenda

• Riassunto ultima sessione

• Opzioni di Backup

– Tecniche e Tools

– Consistenza

• Ambienti Sharded

• MMS Backup

• Recovery

Q & A

• Virtual Genius Bar

– Usate la chat per fare

domande

– Support team è a

disposizione

– Usateli durante le

sessioni!

Riassunto ultima puntata…

Deployment Considerations

• Dimensioni

Working Set

• Durabilità dei Dati

• Replica Set

• Regole di Tag

• Opzioni di Read

Considerazioni di Deployment

• Scale Out

• Partizionamento

• Distribuzione dei

Dati

• Scelta Shard Key

• Fate sharding

quando ne avete

bisogno

Opzioni di Backup

mongodump & mongorestore

Copia del Files system

Files system snapshot

Non usate mongoimport & mongoexport!

Tools & Tecniche

//mongodump Example

server> mongodump -h myhost -d cms -c articles

Crea un .bson file – (e un file json di

metadati)

– Sulla rete o sul file

system.

Mongodump

>mongodump –h myhost -d cms -c articles

connected to: myhost

2014-04-16T12:54:56.758+0100 DATABASE: cms to dump/cms

2014-04-16T12:54:56.759+0100 cms.articles to

dump/cms/articles.bson

2014-04-16T12:54:56.816+0100 7 documents

2014-04-16T12:54:56.817+0100 Metadata for cms.articles to

dump/cms/articles.metadata.json

Sulla rete può introdurre dei page faults

I nodi Primary eSecondary sono identici– A parte la latenza

Usate secondary per backup– Oppure hidden secondary

Da dove posso fare i backup?

mongodump

I dati potenzialmente possono essere inconsistenti– mongodump legge i file del database sequenziale

– Per esempio, fate update di oggetti uno prima e uno dopo

il backup

2 opzioni per mantenere l’integrità dei dati– Usate il parametro –oplog switch sul mongodump.

– Lockate il database in scrittura durante il backup

Consistenza dei Dati di Backup

Esempi di --oplog e --oplogReplay

//Backup with –oplog

//--oplog richiede di effettuare il backup di tutti I

database/collection di quel server

>mongodump –h myhost –oplog

//Per far eil restore usate mongorestore con il parametro --

oplogRelay switch

>mongorestore –h myhost –oplogReplay ./cms/dump

Sia per I nodi primari che secondari– Fa il flish dei dati su disco e fa il lock di tutte le scritture

– Usate db.fsyncLock() & db.fsyncUnlock()

Lock del Database in Scrittura

//use fsync and lock from the mongo shell

> db.fsyncLock()

{

"info" : "now locked against writes, use db.fsyncUnlock() to unlock",

"seeAlso" : "http://dochub.mongodb.org/core/fsynccommand",

"ok" : 1

}

//Perform file system backup… then unlock with… unlocked

secondaries will catchup.

> db.fsyncUnlock()

{ "ok" : 1, "info" : "unlock completed" }

• Copiate I file della vostra directory dei dati (e.g.

/data/db)– Da usare assieme a fsync+lock

• File system or block storage snapshot– Ad esempio snapshot LVM

• Metodo più veloce di backup/restore

• Considerazioni– Journal, Consistenza

– Granularità del Backup (whole file system back up?)

– Esperienza di Ops

– Dove memorizzare I backup o gli snapshopt?

Backup a livello di Storage-level

Fermate il processo di bilanciamento– Aspettate le fine delle migrazioni in corso

– Fate il backup di ogni shard

– Non dimenticate di fare il backup del config!

Backup di un Cluster Sharded

//Switch the balancer off…

mongos> sh.setBalancerState(false)

//Check to see if the balance is currently doing any migrations.

mongos> sh.isBalancerRunning()

Recovery

In caso di una failure– Restore dal backup

• Snapshot / mongodump etc.

• Restart del nodo

– Re-sync da un altro nodo

• I file possono essere copiato da un membro di un replica

set all’altro.

• O I dati se non sono troppo grandi possono essere

sincronizzati via network

Recovery

MMS Backup

On premise

Nel Cloud

Cos’è il MongoDB Management Service?

http://mms.mongodb.com

Architettura del Backup di MMS

• Replication Data

piped into MMS

Backup

• Dal sync iniziale, ricostruiamo I vostri dati neinostri datacenters and periodicamente facciamouno snapshot

• Facciamo gli snapshot ogni 6 ore (on premise fino a 15 minuti)

• Oplog sono memorizzati per 48 ore

Come Funziona

Il Balancer viene messo in pausa ogni 6 ore

Un token di no-op viene inserito in tutti gli shard, mongos e config

Oplog vengono applicati fino al punto di inserimento del token di no-op

Fornisce uno stato consistente del database anche attraverso gli shard

Backup dei Cluster Sharded

Sommario

– Scegliete la soluzione di backup giusta per

voi

– Gli Snapshot sono veloci

– Attenzione al livello di integrità dei dati

richiesto

– Recovery• Dal Backup o da un altro secondary

– MMS Backup ora disponibile• Onsite o nel cloud

Riassunto

– Performance Monitoring– Tuning

– Tools

– Quali metriche sono importanti

Prossima Sessione- 17 Giugno