È una strategia di backup valida per MongoDB?

11

Ho un singolo server dedicato con un database MongoDB di circa 10 GB. Devo eseguire backup giornalieri, ma non posso avere tempi di inattività con il database. È possibile utilizzare un set di repliche su un singolo disco (con 2 istanze di mongod in esecuzione su porte diverse) e semplicemente portare offline quello secondario e eseguire il backup dei file di dati su una memoria esterna come S3 (l'inserimento nel journal è attivato)? O usare master / slave sarebbe meglio di un set di repliche?

È fattibile e, in caso affermativo, quali potenziali problemi potrei avere? In caso contrario, come posso concettualizzare questo per funzionare?

backup database-backup mongodb

— James Simpson
fonte

6

ReplicaSet funzionerà in questo scenario. Tuttavia, non posso dire se avere due istanze MongoDB sullo stesso server sia una buona idea, questo dipende dall'hardware / software del server e dal carico.

Per assicurarsi che il backupnodo MongoDB non diventi master, impostare il priorityparametro su 0, ad es

rs.add({_id: 1, host: "localhost:<port>", priority: 0})

NOTA : se non è possibile avere tempi di inattività, DOVREBBE avere almeno 2 nodi MongoDB primari in ReplicaSet, vedere l' articolo

— Alexander Azarov
fonte

2

Una strategia da considerare è l'utilizzo dell'opzione "nascosta" sul nodo di backup sul set di repliche. Dal blog MongoDB:

I server nascosti non appariranno nei risultati isMaster (). Ciò significa anche che non verranno utilizzati se un driver distribuisce automaticamente le letture agli slave. Un server nascosto deve avere una priorità pari a 0 (non è possibile avere un primario nascosto). Per aggiungere un membro nascosto, eseguire:

rs.add ({"_ id": num, "host": nomehost, "priorità": 0, "nascosto": vero})

— Travis Dunn
fonte

1

I set di repliche sono preferiti in generale, ma anche in questo caso semplicemente a causa della loro funzionalità di ripristino automatico e risincronizzazione automatica. Il metodo di backup che stai descrivendo sembra perfettamente ragionevole ed è stato usato in precedenza anche con altri database.

L'unico potenziale problema che vedo è che in determinate circostanze il tuo secondario potrebbe essere promosso al tuo primario e tu a) dovrai prendere il tuo backup dal nuovo secondario, oppure b) rendere lo script di backup abbastanza intelligente da dire a quell'istanza di MongoDB per dimettersi.

La buona notizia è che dovrebbe essere abbastanza banale

Interroga l'origine del backup per scoprire quale istanza è primaria e quale secondaria ( db.isMaster())
Convincere l'istanza di backup a dimettersi utilizzando i comandi rs.freeze()e o riconnettersi al secondariors.stepDown()

— Charles Hooper
fonte

Non è un'opzione per impostare la priorità su 0 come suggerisce Alexander in modo che il secondario non diventi mai il primario?

— James Simpson,

Dovresti fare alcuni test, ma non sono sicuro che il secondario rimarrà in standby se per qualche motivo il processo primario si interrompe. Ho sempre desiderato che i miei secondari prendessero il sopravvento;)

— Charles Hooper, il

1

>> il tuo secondario può essere promosso a tuo primario - Come accennato, l'impostazione del secondario su priorità 0 impedirà che passi mai al master.

— Jonesome ripristina Monica il

Potresti connetterti a uno qualsiasi dei peer dal tuo elenco di nodi peer (potrebbe essere qualsiasi nodo primario, secondario, arbitro o nascosto), chiedere a quel peer chi sono i secondari ( rs.status()e passare attraverso result["members"]) e connettersi a uno dei secondari per eseguire il backup.

— yfeldblum,