I sistemi di database hanno la responsabilità di archiviare e garantire la disponibilità coerente dei dati rilevanti quando necessario e in qualsiasi momento durante il funzionamento. La maggior parte delle aziende non riesce a continuare l'attività a seguito di casi di perdita di dati a causa di un errore del database, di un bridge di sicurezza, di un errore umano o di un guasto catastrofico che potrebbe distruggere completamente i nodi operativi in produzione. Mantenere i database nello stesso data center espone ad alto rischio di perdere tutti i dati in caso di questi oltraggi.
La replica e il backup sono i metodi comunemente utilizzati per garantire un'elevata disponibilità dei dati. La selezione tra i due dipende dalla frequenza con cui i dati cambiano. Il backup è preferibile quando i dati non cambiano più frequentemente e non ci si aspetta di avere così tanti file di backup. D'altra parte, la replica è preferita per i dati che cambiano frequentemente oltre ad altri vantaggi associati come il servizio di dati in una posizione specifica riducendo la latenza delle richieste. Tuttavia, sia la replica che il backup possono essere utilizzati per la massima integrità e coerenza dei dati durante il ripristino in ogni caso di errore.
I backup del database offrono ulteriori vantaggi oltre a fornire un punto di ripristino per fornire le basi per la creazione di nuovi ambienti per lo sviluppo, l'accesso aperto e lo staging senza intaccare la produzione. Il team di sviluppo può testare rapidamente e facilmente le nuove funzionalità integrate e accelerarne lo sviluppo. I backup possono essere utilizzati anche per il checkpoint per errori di codice laddove i dati risultanti non siano coerenti.
Considerazioni per il backup di MongoDB
I backup vengono creati in determinati punti per riflettere (agendo come un'istantanea del database) quali dati ospita il database in quel dato momento. Se il database si guasta in un determinato punto, possiamo utilizzare l'ultimo file di backup per ripristinare il DB a un punto prima che fallisse. Tuttavia, è necessario prendere in considerazione alcuni fattori prima di eseguire un ripristino e includono:
- Obiettivo punto di ripristino
- Obiettivo tempo di recupero
- Isolamento database e snapshot
- Complicazioni con lo sharding
- Processo di restauro
- Fattori di prestazioni e spazio di archiviazione disponibile
- Flessibilità
- Complessità di distribuzione
Obiettivo punto di recupero
Questa operazione viene eseguita in modo da determinare la quantità di dati che sei pronto a perdere durante il processo di backup e ripristino. Ad esempio, se disponiamo di dati utente e dati del flusso di clic, ai dati dell'utente verrà data la priorità rispetto all'analisi del flusso di clic poiché quest'ultima può essere rigenerata monitorando le operazioni nell'applicazione dopo il ripristino. Un backup continuo dovrebbe essere preferito per i dati critici come le informazioni bancarie, i dati dell'industria di produzione e le informazioni sui sistemi di comunicazione e dovrebbe essere eseguito a intervalli ravvicinati. Se i dati non cambiano frequentemente, potrebbe essere meno costoso perderne gran parte se esegui uno snapshot ripristinato, ad esempio 6 mesi o 1 anno prima.
Obiettivo Tempo di recupero
Questo serve per analizzare e determinare quanto velocemente può essere eseguita l'operazione di ripristino. Durante il ripristino, le tue applicazioni subiranno dei tempi di inattività che sono anche direttamente proporzionali alla quantità di dati che devono essere recuperati. Se stai ripristinando una grande serie di dati, ci vorrà più tempo.
Isolamento database e snapshot
L'isolamento è una misura di quanto siano vicini gli snapshot di backup dai server di database primari in termini di configurazione logica e fisica. Se si trovano abbastanza vicini, il tempo di ripristino si riduce a scapito di una maggiore probabilità di essere distrutti nello stesso momento in cui il database viene distrutto. Non è consigliabile ospitare i backup e l'ambiente di produzione nello stesso sistema per evitare che eventuali interruzioni sui server si riducano anche nei backup.
Complicazioni con lo sharding
Per un sistema di database distribuito tramite sharding, viene presentata una certa complessità di backup e potrebbe essere necessario sospendere le attività di scrittura nell'intero sistema. Shard diversi completeranno diversi tipi di backup in momenti diversi. Considerando i backup logici e i backup snapshot,
Backup logici
- I frammenti sono di dimensioni diverse, quindi finiranno in momenti diversi
- I dump di MongoDB ignoreranno --oplog quindi non saranno coerenti in ogni shard.
- Il bilanciatore potrebbe essere spento mentre dovrebbe essere acceso solo perché alcuni shard potrebbero non aver completato il processo di ripristino
Backup di istantanee
- Funziona bene per una singola replica dalle versioni 3.2 e successive. Dovresti quindi considerare di aggiornare la tua versione di MongoDB.
Processo di restauro
Alcune persone eseguono backup senza verificare se funzioneranno in caso di ripristino. Un backup in sostanza serve a fornire una capacità di ripristino, altrimenti risulterà inutile. Dovresti sempre provare a eseguire i backup su server di prova diversi per vedere se funzionano.
Fattori di prestazioni e spazio di archiviazione disponibile
I backup tendono anche a prendere molte dimensioni come i dati del database stesso e devono essere compressi a sufficienza per non occupare molto spazio non necessario che potrebbe ridurre le risorse di archiviazione complessive del sistema. Possono essere archiviati in file zip riducendo così le loro dimensioni complessive. Inoltre, come accennato in precedenza, è possibile archiviare i backup in datacenter diversi dal database stesso.
I backup possono determinare prestazioni diverse del database in quanto alcuni potrebbero degradarlo. In tal caso, i backup continui renderanno una certa battuta d'arresto, quindi dovrebbero essere convertiti in backup pianificati per evitare l'esaurimento delle finestre di manutenzione. Nella maggior parte dei casi, i server secondari vengono distribuiti per supportare i backup. In questo caso:
- Non è possibile eseguire il backup di nodi singoli in modo coerente perché MongoDB utilizza read-uncommitted senza oplog quando si utilizza il comando mongodump e in tal caso i backup non saranno sicuri.
- Utilizzare i nodi secondari per i backup poiché il processo stesso richiede tempo in base alla quantità di dati coinvolti e le applicazioni collegate subiranno dei tempi di inattività. Se utilizzi il primario che deve aggiornare anche gli Oplog, potresti perdere alcuni dati durante quel periodo di inattività
- Il processo di ripristino richiede molto tempo, ma le risorse di archiviazione assegnate sono minime.
Flessibilità
Molte volte potresti non volere alcuni dei dati durante il backup, come per l'esempio dell'obiettivo del punto di ripristino, potresti voler eseguire il ripristino e filtrare i dati dei clic dell'utente. Per fare ciò, è necessaria una strategia di backup parziale che fornisca la flessibilità necessaria per filtrare i dati che non ti interessano, riducendo così la durata del ripristino e le risorse che sarebbero state sprecate. Il backup incrementale può anche essere utile in modo tale che solo le parti di dati che sono state modificate vengano salvate dall'ultimo snapshot anziché eseguire backup interi per ogni snapshot.
Complessità di distribuzione
La tua strategia di backup dovrebbe essere facile da impostare e mantenere nel tempo. Puoi anche pianificare i tuoi backup in modo da non doverli eseguire manualmente ogni volta che vuoi.
Conclusione
I sistemi di database garantiscono la "vita dopo la morte" solo se è presente un sistema di backup ben consolidato. Il database potrebbe essere distrutto da fattori catastrofici, errori umani o attacchi alla sicurezza che possono portare alla perdita o al danneggiamento dei dati. Prima di eseguire un backup, è necessario considerare il tipo di dati in termini di dimensioni e importanza. Non è sempre consigliabile mantenere i backup nello stesso data center del database in modo da ridurre la probabilità che i backup vengano distrutti contemporaneamente. I backup possono alterare le prestazioni del database, quindi è necessario prestare attenzione alla strategia da utilizzare e quando eseguire il backup. Non eseguire i backup sul nodo primario poiché potrebbe causare tempi di inattività del sistema durante il backup e di conseguenza la perdita di dati importanti.
