Tutti i dati scaricati tramite mongodumpdevono essere letti in memoria dal server MongoDB. Vale anche la pena notare che mongodumpesegue il backup dei dati e delle definizioni dell'indice; il tempo per il ripristino può anche essere significativamente più lungo rispetto ad altri approcci poiché mongorestoresarà necessario ricreare eventuali indici secondari dopo il caricamento dei dati.
Come notato nella documentazione di MongoDB , mongodumpè utile per il backup e il ripristino di piccole distribuzioni ma non è l'ideale per acquisire backup completi di sistemi più grandi:
Quando è collegato a un'istanza MongoDB, mongodump può influire negativamente sulle prestazioni di mongod. Se i tuoi dati sono più grandi della memoria di sistema, le query elimineranno la memoria del set di lavoro, causando errori di pagina.
Un server autonomo limita le opzioni di backup se si desidera anche mantenere la distribuzione disponibile durante l'esecuzione di un backup.
Ecco alcuni approcci suggeriti in ordine dal più al meno raccomandato:
Approccio n. 1: utilizzare un servizio di backup cloud
Per la soluzione più semplice a breve termine, prenderei in considerazione l'utilizzo di un servizio di backup su cloud commerciale come MongoDB Cloud Manager . MongoDB Cloud Manager fornisce backup continui con istantanee pianificate e criteri di conservazione (consultare Preparazione del backup per ulteriori informazioni). Un servizio cloud evita inoltre di dover distribuire qualsiasi server / infrastruttura extra, quindi anche se prevedi di farlo in futuro, questa è una soluzione utile a breve termine.
L'approccio generale sarebbe:
Come ulteriore vantaggio, Cloud Manager include anche un agente di monitoraggio in grado di acquisire la cronologia delle metriche dalla distribuzione e consentire di configurare gli avvisi.
Approccio n. 2: convertire la distribuzione in un set di repliche e eseguire il backup da un secondario nascosto
Questo approccio richiede il provisioning di alcune infrastrutture extra, ma scarica l'impatto del backup dal server primario. In genere, ai set di repliche viene eseguito il provisioning con almeno tre membri per la disponibilità elevata e il failover automatico, ma se l'unico obiettivo è il backup è possibile utilizzare una configurazione a due server meno ideale.
L'approccio generale sarebbe:
- Fornire un secondo server che verrà utilizzato per il backup
- Converti il tuo server autonomo in un set di repliche .
- Aggiungi il tuo server di backup come secondario nascosto con una priorità di 0 (non diventerà mai primario) e 0 voti.
- Utilizzare uno dei metodi di backup supportati per eseguire i backup sul secondario nascosto. I metodi di backup sono elencati in ordine generale di raccomandazione:
mongodsono preferibili le istantanee del filesystem (se supportate dalla configurazione) o la copia del file (supponendo che si interrompa ) mongodump.
- (idealmente) aggiungi un altro secondario contenente dati se desideri i vantaggi di alta disponibilità e failover di una configurazione del set di repliche.
Approccio n. 3: utilizzare le istantanee del filesystem (se disponibili e appropriate)
Una strategia di backup meno efficace della tua attuale mongodumpsarebbe quella di utilizzare snapshot del filesystem , supponendo che tu abbia un filesystem che supporti gli snapshot (e tutti i tuoi file di dati e journal sono su un singolo volume in modo da poter ottenere un'istantanea coerente di una corsa mongod). Il vantaggio degli snapshot del filesystem è che non tutti i dati devono essere letti in memoria mongod, tuttavia gli snapshot possono comunque avere un impatto (in particolare quando si crea lo snapshot iniziale su un sistema occupato). Le istantanee successive sono più efficienti e meno impattanti, ma non sono ancora una soluzione di backup completa in quanto le istantanee sono locali per il tuo server (e al momento hai solo uno standalone).
Avvertenze
Gli approcci n. 1 e n. 2 prevedono entrambi l'abilitazione della replica per facilitare i backup. La replica aggiungerà alcuni I / O locali aggiuntivi sul server primario poiché tutte le operazioni di scrittura sono annotate in una raccolta con limite speciale denominata oplog (registro delle operazioni) .
In futuro hai menzionato una probabile necessità di sharding, ma prima di farlo isolerei il tuo carico di lavoro MongoDB dagli altri processi che condividono lo stesso server. Se puoi modificare la tua strategia di backup in qualcosa di più efficiente di mongodump, rimuovere la contesa di risorse e acquisire un po 'di cronologia delle metriche di base per la revisione ... potresti scoprire che lo sharding non è ancora richiesto.