Le interruzioni di produzione sono quasi garantite prima o poi. Accettare questo fatto e analizzare la sequenza temporale e lo scenario di errore dell'interruzione del database può aiutare a prepararsi, diagnosticare e ripristinare meglio il successivo. Per mitigare l'impatto dei tempi di inattività, le organizzazioni necessitano di un piano di ripristino di emergenza (DR) appropriato. La pianificazione del ripristino di emergenza è un'attività critica per molti SysOps/DevOps, ma anche se è prevista; spesso non esiste.
In questo post del blog, analizzeremo diversi scenari di backup e di errore nei sistemi di database MongoDB. Ti guideremo anche attraverso le procedure di ripristino e failover per ogni rispettivo scenario. Questi casi d'uso variano dal ripristino di un singolo nodo, al ripristino di un nodo in un replicaSet esistente e al seeding di un nuovo nodo in un replicaSet. Si spera che questo ti dia una buona comprensione dei rischi che potresti incontrare e cosa considerare quando progetti la tua infrastruttura.
Prima di iniziare a discutere di possibili scenari di errore, diamo un'occhiata a come MongoDB archivia i dati e quali tipi di backup sono disponibili.
Come MongoDB memorizza i dati
MongoDB è un database orientato ai documenti. Invece di archiviare i tuoi dati in tabelle composte da singole righe (come fa un database relazionale), memorizza i dati in raccolte composte da singoli documenti. In MongoDB, un documento è un grande BLOB JSON senza un formato o uno schema particolare. Inoltre, i dati possono essere distribuiti su diversi nodi del cluster con condivisione o replicati su server slave con replicaSet.
MongoDB consente scritture e aggiornamenti molto veloci per impostazione predefinita. Il compromesso è che spesso non vieni esplicitamente informato dei guasti. Per impostazione predefinita, la maggior parte dei driver esegue scritture asincrone e non sicure. Ciò significa che il driver non restituisce direttamente un errore, simile a INSERT DELAYED con MySQL. Se vuoi sapere se qualcosa è riuscito, devi controllare manualmente la presenza di errori usando getLastError.
Per prestazioni ottimali, è preferibile utilizzare SSD anziché HDD per l'archiviazione. È necessario accertarsi che lo spazio di archiviazione sia locale o remoto e adottare le misure di conseguenza. È meglio utilizzare RAID per la protezione di difetti hardware e schemi di ripristino, ma non fare affidamento completamente su di esso poiché non offre protezione contro guasti avversi. L'hardware giusto è l'elemento costitutivo della tua applicazione per ottimizzare le prestazioni ed evitare una grave debacle.
Il danneggiamento dei dati a livello di disco o la mancanza di file di dati possono impedire l'avvio delle istanze mongod e i file journal potrebbero non essere sufficienti per il ripristino automatico.
Se si esegue con il journaling abilitato, non è quasi mai necessario eseguire la riparazione poiché il server può utilizzare i file journal per ripristinare automaticamente i file di dati in uno stato pulito. Tuttavia, potrebbe essere comunque necessario eseguire la riparazione nei casi in cui è necessario eseguire il ripristino dal danneggiamento dei dati a livello di disco.
Se il journaling non è abilitato, l'unica opzione potrebbe essere eseguire il comando di riparazione. mongod --repair dovrebbe essere utilizzato solo se non hai altre opzioni poiché l'operazione rimuove (e non salva) i dati corrotti durante il processo di riparazione. Questo tipo di operazione deve essere sempre preceduta da backup.
Scenario di ripristino di emergenza di MongoDB
In un piano di ripristino in caso di errore, il tuo obiettivo del punto di ripristino (RPO) è un parametro di ripristino chiave che determina la quantità di dati che puoi permetterti di perdere. L'RPO è elencato nel tempo, da millisecondi a giorni e dipende direttamente dal tuo sistema di backup. Considera l'età dei tuoi dati di backup che devi recuperare per riprendere le normali operazioni.
Per stimare l'RPO devi farti alcune domande. Quando viene eseguito il backup dei miei dati? Qual è lo SLA associato al recupero dei dati? Il ripristino di un backup dei dati è accettabile o i dati devono essere online e pronti per essere interrogati in qualsiasi momento?
Le risposte a queste domande ti aiuteranno a individuare il tipo di soluzione di backup di cui hai bisogno.
Soluzioni di backup MongoDB
Le tecniche di backup hanno impatti variabili sulle prestazioni del database in esecuzione. Alcune soluzioni di backup riducono le prestazioni del database a sufficienza da rendere necessario pianificare i backup per evitare picchi di utilizzo o finestre di manutenzione. Potresti decidere di implementare nuovi server secondari solo per supportare i backup.
Le tre soluzioni più comuni per eseguire il backup del server/cluster MongoDB sono...
- Mongodump/Mongorestore - backup logico.
- Mongo Management System (Cloud):è possibile eseguire il backup dei database di produzione utilizzando MongoDB Ops Manager oppure, se si utilizza il servizio MongoDB Atlas, è possibile utilizzare una soluzione di backup completamente gestita.
- Istantanee del database (backup a livello di disco)
Mongodump/Mongorestore
Quando si esegue un mongodump, tutte le raccolte all'interno dei database designati verranno scaricate come output BSON. Se non viene specificato alcun database, MongoDB eseguirà il dump di tutti i database ad eccezione dei database admin, test e locali poiché sono riservati per uso interno.
Per impostazione predefinita, mongodump creerà una directory denominata dump, con una directory per ogni database contenente un file BSON per raccolta in quel database. In alternativa, puoi dire a mongodump di archiviare il backup in un unico file di archivio. Il parametro archive concatenerà l'output di tutti i database e le raccolte in un unico flusso di dati binari. Inoltre, il parametro gzip può naturalmente comprimere questo archivio, usando gzip. In ClusterControl eseguiamo lo streaming di tutti i nostri backup, quindi abilitiamo sia l'archivio che i parametri gzip.
Simile a mysqldump con MySQL, se crei un backup in MongoDB bloccherà le raccolte mentre scaricherà il contenuto nel file di backup. Poiché MongoDB non supporta le transazioni (modificato in 4.2), non è possibile eseguire un backup completamente coerente al 100% a meno che non si crei il backup con il parametro oplog. L'abilitazione di questa opzione sul backup include le transazioni dell'oplog in esecuzione durante l'esecuzione del backup.
Per una migliore automazione e puoi eseguire MongoDB dalla riga di comando o utilizzare strumenti esterni come ClusterControl. ClusterControl è un'opzione consigliata per la gestione del backup e l'automazione del backup, poiché consente di creare strategie di backup avanzate per vari sistemi di database open source.
ClusterControl ti consente di caricare il backup nel cloud. Supporta il backup completo e ripristina la crittografia di mongodump. Se vuoi vedere come funziona c'è una demo sul nostro sito web.
Ripristino di MongoDB da un backup
Ci sono fondamentalmente due modi per utilizzare un dump in formato BSON:
- Esegui mongod direttamente dalla directory di backup
- Esegui mongorestore e ripristina il backup
Esegui mongod direttamente da un backup
Un prerequisito per eseguire mongod direttamente dal backup è che la destinazione del backup sia un dump standard e non sia compresso con gzip.
Il demone MongoDB verificherà quindi l'integrità della directory dei dati, aggiungerà il database di amministrazione, i giornali, i cataloghi delle raccolte e degli indici e alcuni altri file necessari per eseguire MongoDB. Se in precedenza è stato eseguito WiredTiger come motore di archiviazione, ora eseguirà le raccolte esistenti come MMAP. Per semplici dump di dati o controlli di integrità, questo funziona bene.
Mongorestore in esecuzione
Un modo migliore per ripristinare sarebbe ovviamente ripristinare il nodo utilizzando un mongorestore.
mongorestore dump/Questo ripristinerà il backup nelle impostazioni predefinite del server (localhost, porta 27017) e sovrascriverà tutti i database nel backup che risiedono su questo server. Ora ci sono tonnellate di parametri per manipolare il processo di ripristino e tratteremo alcuni di quelli importanti.
In ClusterControl questo viene fatto nell'opzione di ripristino del backup. Puoi scegliere la macchina quando il backup verrà ripristinato ed elaborato con cura del resto. Ciò include il backup crittografato in cui normalmente dovresti anche decrittografare il backup.
Convalida oggetto
Poiché il backup contiene dati BSON, ti aspetteresti che il contenuto del backup sia corretto. Tuttavia, per cominciare, potrebbe essere stato il caso che il documento che è stato scaricato fosse malformato. Mongodump non verifica l'integrità dei dati che esegue il dump.
Per affrontare tale uso -- objcheck che obbliga mongorestore a convalidare tutte le richieste dei clienti al momento della ricezione per garantire che i clienti non inseriscano mai documenti non validi nel database. Può avere un piccolo impatto sulle prestazioni.
Riproduzione Oplog
Oplog al tuo backup ti consentirà di eseguire un backup coerente ed eseguire un ripristino point-in-time. Abilita il parametro oplogReplay per applicare l'oplog durante il processo di ripristino. Per controllare fino a che punto riprodurre l'oplog, puoi definire un timestamp nel parametro oplogLimit. Verranno quindi applicate solo le transazioni fino al timestamp.
Ripristino di un ReplicaSet completo da un backup
Il ripristino di un replicaSet non è molto diverso dal ripristino di un singolo nodo. O devi prima configurare il replicaSet e ripristinarlo direttamente nel replicaSet. Oppure si ripristina prima un singolo nodo e quindi si utilizza questo nodo ripristinato per creare un replicaSet.
Ripristina prima il nodo, quindi crea replicaSet
Ora il secondo e il terzo nodo sincronizzeranno i loro dati dal primo nodo. Al termine della sincronizzazione, il nostro replicaSet è stato ripristinato.
Crea prima un ReplicaSet, quindi ripristina
Diversamente dal processo precedente, puoi prima creare il replicaSet. Prima configura tutti e tre gli host con replicaSet abilitato, avvia tutti e tre i daemon e avvia replicaSet sul primo nodo:
Ora che abbiamo creato il replicaSet, possiamo ripristinare direttamente il nostro backup in esso:
Secondo noi ripristinare un replicaSet in questo modo è molto più elegante. È più simile al modo in cui normalmente configureresti un nuovo set di replica da zero e poi lo riempirai con i dati (di produzione).
Seminare un nuovo nodo in un ReplicaSet
Quando si ridimensiona un cluster aggiungendo un nuovo nodo in MongoDB, deve avvenire la sincronizzazione iniziale del set di dati. Con la replica MySQL e Galera, siamo così abituati a utilizzare un backup per avviare la sincronizzazione iniziale. Con MongoDB questo è possibile, ma solo facendo una copia binaria della directory dei dati. Se non hai i mezzi per creare uno snapshot del file system, dovrai affrontare i tempi di inattività su uno dei nodi esistenti. Il processo, con i tempi di fermo, è descritto di seguito.
Semina con un backup
Quindi cosa accadrebbe se si ripristinasse invece il nuovo nodo da un backup mongodump e lo si unisse a un replicaSet? Il ripristino da un backup dovrebbe, in teoria, fornire lo stesso set di dati. Poiché questo nuovo nodo è stato ripristinato da un backup, mancherà di replicaSetId e MongoDB lo noterà. Poiché MongoDB non vede questo nodo come parte di replicaSet, il comando rs.add() attiverà sempre la sincronizzazione iniziale di MongoDB. La sincronizzazione iniziale attiverà sempre l'eliminazione di tutti i dati esistenti sul nodo MongoDB.
Il replicaSetId viene generato all'avvio di un replicaSet e sfortunatamente non può essere impostato manualmente. È un peccato perché il ripristino da un backup (inclusa la riproduzione dell'oplog) ci darebbe teoricamente un set di dati identico al 100%. Sarebbe bello se la sincronizzazione iniziale fosse facoltativa in MongoDB per soddisfare questo caso d'uso.
