Est-ce une stratégie de sauvegarde valide pour MongoDB?

11

J'ai un seul serveur dédié avec une base de données MongoDB d'environ 10 Go. J'ai besoin de faire des sauvegardes quotidiennes, mais je ne peux pas avoir de temps d'arrêt avec la base de données. Est-il possible d'utiliser un jeu de réplicas sur un seul disque (avec 2 instances de mongod s'exécutant sur des ports différents), et simplement mettre le secondaire hors ligne et sauvegarder les fichiers de données sur un stockage hors site tel que S3 (la journalisation est activée)? Ou serait-il préférable d'utiliser maître / esclave qu'un jeu de répliques?

Est-ce viable, et si oui, quels problèmes potentiels pourrais-je avoir? Sinon, comment conceptualiser cela pour fonctionner?

backup database-backup mongodb

— James Simpson
source

6

ReplicaSet fonctionnera dans ce scénario. Cependant, je ne peux pas dire si avoir deux instances MongoDB sur le même serveur est une bonne idée - cela dépend du matériel / logiciel et de la charge du serveur.

Pour vous assurer que votre backupnœud MongoDB ne devient pas maître, définissez son priorityparamètre sur 0, par exemple

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

REMARQUE : si vous ne pouvez pas avoir de temps d'arrêt, vous DEVRIEZ avoir au moins 2 nœuds MongoDB principaux dans ReplicaSet, voir l' article

— Alexander Azarov
source

2

Une stratégie à envisager consiste à utiliser l'option "masqué" sur le nœud de sauvegarde de votre jeu de réplicas. Depuis le blog MongoDB:

Les serveurs masqués n'apparaîtront pas dans les résultats isMaster (). Cela signifie également qu'ils ne seront pas utilisés si un pilote distribue automatiquement les lectures aux esclaves. Un serveur masqué doit avoir une priorité de 0 (vous ne pouvez pas avoir de serveur primaire masqué). Pour ajouter un membre masqué, exécutez:

rs.add ({"_ id": num, "host": hostname, "priority": 0, "hidden": true})

— Travis Dunn
source

1

Les jeux de réplicas sont préférés en général mais aussi dans ce cas simplement en raison de leur fonctionnalité de récupération automatique et de resynchronisation automatique. La méthode de sauvegarde que vous décrivez semble parfaitement raisonnable et a déjà été utilisée avec d'autres bases de données.

Le seul problème potentiel que je vois est que, dans certaines circonstances, votre secondaire peut être promu à votre principal et vous aurez soit a) besoin de prendre votre sauvegarde du nouveau secondaire, ou b) de rendre votre script de sauvegarde assez intelligent pour indiquer à cette instance de MongoDB pour démissionner.

La bonne nouvelle est qu'il devrait être assez banal de

Recherchez votre source de sauvegarde pour savoir quelle instance est principale et laquelle est secondaire ( db.isMaster())
Convaincre l'instance de sauvegarde de démissionner à l'aide des commandes rs.freeze()et ou de se reconnecter au secondairers.stepDown()

— Charles Hooper
source

N'est-ce pas une option pour définir la priorité à 0 comme Alexander le suggère afin que le secondaire ne devienne jamais le primaire?

— James Simpson

Il faudrait faire des tests, mais je ne sais pas si le secondaire se mettra en veille si, pour une raison quelconque, le processus principal tombe en panne. J'ai toujours voulu que mes secondaires prennent le relais;)

— Charles Hooper

1

>> votre secondaire peut être promu à votre primaire - Comme mentionné, la définition du secondaire sur la priorité 0 l'empêchera de passer en maître.

— Jonesome Reinstate Monica

Vous pouvez vous connecter à l'un des homologues de votre liste de nœuds homologues (il peut s'agir de n'importe quel nœud principal, secondaire, arbitre ou masqué), demander à cet homologue qui sont les secondaires ( rs.status()et boucler result["members"]) et vous connecter à l'un des secondaires pour effectuer la sauvegarde.

— yfeldblum