Qual è il modo consigliato per eseguire il backup di set di dati di grandi dimensioni in MongoDB? Supponiamo che abbiamo una dimensione dei dati dell'ordine di 10 TB: come eseguiresti il ​​backup?

Stiamo considerando un nodo set di repliche nascosto, possibilmente ritardato. Il ritardo ci proteggerebbe da cadute accidentali dell'intero database. È una soluzione praticabile e quali altre opzioni consiglieresti di indagare?

Grazie!

Con la necessità di eseguire il backup di 10 TB questo diventa un po 'complicato.

Le repliche non sostituiscono i backup corretti

Mentre i membri ritardati del set di repliche possono fornire un modo relativamente semplice di aiutarvi con operazioni accidentali, non vi sono sostituti per i backup corretti, proprio come RAID non sostituisce i backup basati su file system.

raccomandazioni

Ciò dipende fortemente dall'aspetto della configurazione.

Istantanee SAN

Con 10 TB, suppongo che abbiate una sorta di SAN collegata. Il modo più semplice per eseguire il backup di MongoDB in quegli ambienti è assicurarsi di avere attivato il journaling sia sul filesystem che su MongoDB e semplicemente scattare un'istantanea sul volume SAN di uno dei secondari, probabilmente uno nascosto per assicurarsi che le operazioni essere interrotto. Questo di solito richiede pochi secondi, ma per favore _ assicurati che la tua finestra di dialogo di replica sia sufficiente. Altrimenti, potrebbe essere necessario risincronizzare il secondario.

Non usare mongodump

Non sono d'accordo con RolandoMySQLDBA sull'uso di mongodump. Prima di tutto, impone blocchi sul server. Sebbene vengano sollevati relativamente velocemente, il numero di blocchi potrebbe aumentare e interferire con le operazioni, a meno che non venga eseguito su un nodo nascosto o quando non vi è alcuna preferenza di lettura che colpisce i secondari. Inoltre, non è esattamente veloce. Mi aspetto che duri almeno per ore, molto probabilmente impiegando più tempo della finestra di backup. Nota a margine : eseguire sempre mongodump con l' --oplogopzione. Tieni inoltre presente che mongodump non esegue il backup degli indici, ma le operazioni per creare indici. Tali indici devono essere ricreati durante un ripristino, il che può aumentare notevolmente il tempo necessario per esso. Dalla mia esperienza, se devi ripristinare un database, vuoi averlo il più velocemente possibile. Un altro punto per cui mongodump non è adatto per il backup di 10 TB.

Note sugli snapshot LVM

È possibile eseguire un'istantanea LVM su un'istanza di mongod in esecuzione a condizione che il journaling sia abilitato in mongod (e dalla mia esperienza, non fa male averlo abilitato anche a livello di FS). Tuttavia, le istantanee LVM hanno alcune implicazioni. Innanzitutto, è necessario disporre di spazio su disco sufficiente per apportare le modifiche durante le operazioni di backup. Vorrei chiarirlo.

Supponiamo che tu abbia una frequenza oraria di cambio di 500 GB. E che si desidera che il backup venga avviato prima che venga caricato in un certo spazio di archiviazione. Anche quando si utilizza bzip2 parallelo , la compressione di 10 TB avrebbe bisogno di alcune ore per terminare, semplicemente perché il fatto che molto probabilmente il rendimento della memoria di massa diventerebbe il tuo fattore limitante. Supponiamo che occorrerebbero 2 ore per comprimere i dati a 2 TB. Quindi ormai avremmo bisogno di circa 2 TB + 2 * 500 GB di spazio libero su disco totale, 1 TB necessario per l'istantanea LVM. Ciò creerebbe almeno la necessità di eseguire il provisioning eccessivo del filesystem30%. Nel caso in cui si desideri disporre di un adeguato margine di sicurezza, questo potrebbe facilmente aumentare al 60-70% (20% per un fattore di utilizzo di 0,8 per il file system originale, lo stesso per la dimensione dell'istantanea più lo spazio necessario per il backup con zip in se stesso ). Nella maggior parte degli ambienti di produzione, ciò sarebbe inaccettabile, dal momento che il provisioning eccessivo sarebbe statico (non vorresti che uno script di backup si manipolasse in modo dinamico con LVM, vero?).

Backup MMS

Sebbene il backup MMS abbia alcune fantastiche funzionalità (backup continuo, ripristino semplificato nel tempo), presenta alcuni seri inconvenienti: il suo prezzo per le distribuzioni di grandi dimensioni può essere facilmente tra le migliaia. Con una presunta variazione oraria di 500 GB su quei 10 TB, sarebbe una somma media di sei cifre per i backup su cloud . Mensile.

Il mio suggerimento è di sottoscrivere un abbonamento aziendale per i server per essere idoneo a disporre di un'istanza MMS locale, incluso il backup.

Sommario

Ecco le opzioni che vorrei prendere in ordine decrescente di preferenza.

1. Istantanee SAN: facili da implementare, relativamente economiche
2. Abbonamento Enterprise: migliori funzionalità. Installalo, configuralo, dimenticalo, è lì quando ne hai bisogno
3. Istantanee LVM: facili da implementare, ma i costi del provisioning eccessivo necessario possono riassumersi nel tempo.

Vi sono due opzioni

BACKUP FISICO

Se non ti dispiace i tempi morti, la cosa più semplice da fare è

service mongod stop

Esegui un'istantanea LVM o una forza bruta cpdella cartella di dati Mongo su un altro disco

service mongod start

Naturalmente, non si vogliono tempi di inattività se i 10 TB di dati si trovano su un computer autonomo.

SET DI REPLICA RITARDATO

Se si dispone di una replica impostata con tre nodi, utilizzare uno dei nodi per i backup

{
        "_id" : "myreplica",
        "version" : 1,
        "members" : [
                {
                        "_id" : 1,
                        "host" : "10.20.30.40:27017",
                        "priority" : 2
                },
                {
                        "_id" : 2,
                        "host" : "10.20.30.41:27017"
                },
                {
                        "_id" : 3,
                        "host" : "10.20.30.42:27017",
                        "priority" : 0,
                        "slaveDelay" : 3600
                }
        ]
}

Utilizzare il nodo con "_id' : 3tutti i backup fisici. Pertanto, nessun tempo morto. Per ottenere uno snapshot di mezzanotte, è possibile avviare il backup all'1: 00 poiché il nodo nascosto è indietro di 1 ora.

Naturalmente, lo svantaggio è di avere altri due server con 10 TB ciascuno e la sanità mentale del sysadmin a rischio.

MONGODUMP

È possibile utilizzare mongodump sul computer autonomo ma è necessario prevedere un peggioramento delle prestazioni poiché mongodump è un programma client che utilizza una connessione come qualsiasi altra connessione.

Se si desidera un backup temporizzato, è necessario utilizzare

mongodump --oplog 

Il backup logico BSON sarà più piccolo (in particolare gzip o bzip) rispetto al backup fisico.

L'utilizzo mongodump --oplogsarebbe meglio sul nodo nascosto. In questo modo, non ci sono hit di performance sul Master.

NEGAZIONE

Sono relativamente nuovo in MongoDB (MongoDBA accidentale / incidentale). Spero che la mia risposta sia d'aiuto.