Quelle est la méthode recommandée pour sauvegarder des ensembles de données volumineux dans MongoDB? Disons que nous avons une taille de données de l'ordre de 10 To - comment voulez-vous sauvegarder cela?

Nous envisageons un nœud de jeu de répliques caché, éventuellement retardé. Le retard nous protégerait des chutes accidentelles de toute la base de données. Est-ce une solution viable et quelles autres options recommanderiez-vous d'étudier?

Merci!

Avec la nécessité de sauvegarder 10 To, cela devient un peu compliqué.

Les répliques ne remplacent pas les sauvegardes appropriées

Bien que les membres du jeu de répliques retardés puissent fournir un moyen relativement facile de vous aider dans les opérations accidentelles, il n'y a pas de remplacement pour les sauvegardes appropriées, tout comme RAID ne remplace pas les sauvegardes basées sur le système de fichiers.

Recommandations

Cela dépend fortement de l'apparence de votre configuration.

Instantanés SAN

Avec 10 To, je suppose que vous avez une sorte de SAN connecté. La façon la plus simple de sauvegarder MongoDB dans ces environnements est de vous assurer que la journalisation est activée à la fois sur le système de fichiers et sur MongoDB et de prendre simplement un instantané du volume SAN de l'un des secondaires, éventuellement caché pour vous assurer que vos opérations ne ne vous interrompez pas. Cela ne prend généralement que quelques secondes, mais assurez-vous que votre fenêtre d'oplog de réplication est suffisante. Sinon, vous devrez peut-être resynchroniser le secondaire.

N'utilisez pas mongodump

Je dois être en désaccord avec RolandoMySQLDBA sur l'utilisation de mongodump. Tout d'abord, il impose des verrous sur le serveur. Bien qu'ils soient levés relativement rapidement, le nombre limité de verrous peut s'additionner et interférer avec vos opérations, à moins qu'ils ne soient exécutés sur un nœud caché ou lorsqu'aucune préférence de lecture ne frappe les secondaires. De plus, ce n'est pas exactement rapide. Je m'attends à ce qu'il fonctionne pendant des heures, au moins, probablement en prenant plus de temps que votre fenêtre de sauvegarde. Note latérale: toujours exécuter mongodump avec l' --oplogoption. Gardez également à l'esprit que mongodump ne sauvegarde pas les index, mais les opérations pour créer des index. Ces indices doivent être recréés lors d'une restauration, ce qui peut augmenter considérablement le temps dont vous avez besoin. D'après mon expérience, si vous devez restaurer une base de données, vous voulez l'avoir le plus rapidement possible. Un autre point pourquoi mongodump n'est pas adapté pour sauvegarder 10 To.

Remarques sur les instantanés LVM

Vous pouvez faire un instantané LVM sur une instance de mongod en cours d'exécution à condition que la journalisation soit activée dans mongod (et d'après mon expérience, cela ne fait pas de mal de l'avoir activée au niveau FS également). Cependant, les instantanés LVM ont certaines implications. Tout d'abord, vous devez évidemment disposer de suffisamment d'espace disque pour pouvoir effectuer les modifications pendant les opérations de sauvegarde. Permettez-moi de clarifier cela.

Supposons que vous ayez un taux de changement horaire de 500 Go. Et que vous souhaitez que votre sauvegarde soit effacée avant qu'elle ne soit téléchargée sur un espace de stockage. Même lors de l'utilisation de bzip2 parallèle , la compression de 10 To nécessiterait quelques heures pour se terminer, tout simplement parce que le débit de stockage de masse deviendrait probablement votre facteur limitant. Supposons qu'il faudrait 2 heures pour compresser les données à 2 To. Donc, maintenant, nous aurions besoin de 2 To + 2 * 500 Go d'espace disque total, 1 To requis pour l'instantané LVM. Cela créerait le besoin de surapprovisionner votre système de fichiers d' au moins30%. Dans le cas où vous souhaitez avoir une marge de sécurité appropriée, cela pourrait facilement augmenter à 60-70% (20% pour un facteur d'utilisation de 0,8 pour le système de fichiers d'origine, le même pour la taille de l'instantané plus l'espace nécessaire pour la sauvegarde bzippée elle-même ). Dans la plupart des environnements de production, cela serait inacceptable, car ce sur-approvisionnement serait statique (vous ne voudriez pas qu'un script de sauvegarde gêne dynamiquement votre LVM, n'est-ce pas?).

Sauvegarde MMS

Alors que la sauvegarde MMS possède des fonctionnalités impressionnantes (sauvegarde continue, récupération facile à un point dans le temps), elle présente de sérieux inconvénients: son prix pour les déploiements importants peut facilement se chiffrer par milliers. Avec un taux de variation horaire supposé de 500 Go sur ces 10 To, ce serait une somme moyenne à six chiffres pour les sauvegardes dans le cloud . Mensuel.

Ma suggestion serait de souscrire un abonnement entreprise à vos serveurs pour pouvoir bénéficier d'une instance MMS sur site, y compris la sauvegarde.

Sommaire

Voici les options que je prendrais par ordre décroissant de préférence.

1. Instantanés SAN: faciles à mettre en œuvre, relativement bon marché
2. Abonnement entreprise: Meilleures fonctionnalités. Installez-le, configurez-le, oubliez-le, il est là quand vous en avez besoin
3. Instantanés LVM: faciles à implémenter, mais les coûts de sur-approvisionnement nécessaires peuvent résumer au fil du temps.

Il y a deux options

SAUVEGARDE PHYSIQUE

Si cela ne vous dérange pas, la chose la plus simple à faire est

service mongod stop

Faire un instantané LVM ou une force brute cpdu dossier de données Mongo sur un autre disque

service mongod start

Bien sûr, vous ne voulez pas de temps d'arrêt si les 10 To de données se trouvent sur une machine autonome.

ENSEMBLE DE RÉPLIQUE RETARDÉE

Si vous avez un jeu de réplicas avec trois nœuds, utilisez l'un des nœuds pour les sauvegardes

{
        "_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
                }
        ]
}

Utilisez le nœud avec "_id' : 3toutes vos sauvegardes physiques. Par conséquent, aucun temps d'arrêt. Pour obtenir un instantané à minuit, vous pouvez lancer la sauvegarde à 1h00 du matin car le nœud caché a 1 heure de retard.

Bien sûr, l'inconvénient est d'avoir deux serveurs supplémentaires avec 10 To chacun et la santé mentale du sysadmin en danger.

MONGODUMP

Vous pouvez utiliser mongodump sur la machine autonome mais vous devez vous attendre à une dégradation des performances car mongodump est un programme client utilisant une connexion comme toute autre connexion.

Si vous souhaitez une sauvegarde ponctuelle, vous devez utiliser

mongodump --oplog 

La sauvegarde BSON logique sera plus petite (en particulier gzippée ou bzippée) que la sauvegarde physique.

Il mongodump --oplogserait préférable d'utiliser le nœud caché. De cette façon, aucune performance n'est atteinte sur le Master.

AVERTISSEMENT

Je suis relativement nouveau sur MongoDB (MongoDBA accidentel / accidentel). J'espère que ma réponse vous aidera.