Toutes les données transférées via mongodumpdoivent être lues en mémoire par le serveur MongoDB. Il convient également de noter que mongodumpsauvegarde les définitions de données et d'index; le temps de restauration peut également être considérablement plus long par rapport à d'autres approches, car mongorestoreil devra recréer tous les index secondaires après le chargement des données.
Comme indiqué dans la documentation MongoDB , mongodumpest utile pour sauvegarder et restaurer de petits déploiements mais n'est pas idéal pour capturer des sauvegardes complètes de systèmes plus grands:
Lorsqu'il est connecté à une instance MongoDB, mongodump peut affecter négativement les performances de mongod. Si vos données sont plus grandes que la mémoire système, les requêtes pousseront l'ensemble de travail hors de la mémoire, provoquant des défauts de page.
Un serveur autonome limite vos options de sauvegarde si vous souhaitez également garder votre déploiement disponible tout en effectuant une sauvegarde.
Voici quelques approches suggérées par ordre de plus à moins recommandé:
Approche n ° 1: utiliser un service de sauvegarde cloud
Pour la solution à court terme la plus simple, j'envisagerais d'utiliser un service de sauvegarde cloud commercial comme MongoDB Cloud Manager . MongoDB Cloud Manager fournit une sauvegarde continue avec des instantanés planifiés et une politique de rétention (voir Préparatifs de sauvegarde pour plus d'informations). Un service cloud vous évite également de devoir déployer des serveurs / infrastructures supplémentaires, donc même si vous prévoyez de le faire à l'avenir, c'est une solution utile à court terme.
L'approche générale serait:
Comme avantage supplémentaire, Cloud Manager comprend également un agent de surveillance qui peut capturer l' historique des métriques de votre déploiement et vous permettre de configurer des alertes.
Approche n ° 2: convertir votre déploiement en jeu de réplicas et sauvegarde à partir d'un secondaire caché
Cette approche nécessite de provisionner une infrastructure supplémentaire, mais décharge l'impact de la sauvegarde de votre serveur principal. En règle générale, les jeux de réplicas sont provisionnés avec au moins trois membres pour la haute disponibilité et le basculement automatique, mais si votre seul objectif est la sauvegarde, vous pouvez utiliser une configuration à deux serveurs moins idéale.
L'approche générale serait:
- Provisionner un deuxième serveur qui sera utilisé pour la sauvegarde
- Convertissez votre serveur autonome en jeu de réplicas .
- Ajoutez votre serveur de sauvegarde en tant que secondaire caché avec une priorité de 0 (il ne deviendra jamais principal) et 0 votes.
- Utilisez l'une des méthodes de sauvegarde prises en charge pour effectuer des sauvegardes sur votre secondaire caché. Les méthodes de sauvegarde sont répertoriées par ordre général de recommandation: les instantanés du système de fichiers (si pris en charge par votre configuration) ou la copie de fichiers (en supposant que vous vous arrêtez
mongod) sont préférables mongodump.
- (idéalement) ajoutez un autre secondaire porteur de données si vous souhaitez bénéficier des avantages de haute disponibilité et de basculement d'une configuration de jeu de réplicas.
Approche n ° 3: utiliser des instantanés du système de fichiers (si disponibles et appropriés)
Une stratégie de sauvegarde moins impactante que votre actuelle mongodumpconsisterait à utiliser des instantanés de système de fichiers , en supposant que vous avez un système de fichiers qui prend en charge les instantanés (et que tous vos fichiers de données et de journaux se trouvent sur un seul volume afin que vous puissiez obtenir un instantané cohérent d'une exécution mongod). L'avantage des instantanés de système de fichiers est que toutes les données ne doivent pas être lues en mémoire mongod, mais les instantanés peuvent toujours avoir un impact (en particulier lors de la création de l'instantané initial sur un système occupé). Les snapshots successifs sont plus efficaces et moins impactants, mais ne sont toujours pas une solution de sauvegarde complète car les snapshots sont locaux sur votre serveur (et vous n'en avez qu'un autonome pour le moment).
Avertissements
Les approches # 1 et # 2 impliquent toutes deux d'activer la réplication pour faciliter les sauvegardes. La réplication ajoutera des E / S locales supplémentaires sur votre serveur principal car toutes les opérations d'écriture sont notées dans une collection plafonnée spéciale appelée oplog (journal des opérations) .
Vous avez mentionné un besoin probable de partage à l'avenir, mais avant de le faire, j'isolerais votre charge de travail MongoDB des autres processus partageant le même serveur. Si vous pouvez changer votre stratégie de sauvegarde en quelque chose de plus efficace que mongodump, supprimer les conflits de ressources et capturer un historique des métriques de référence pour examen ... vous constaterez peut-être que le partage n'est pas encore requis.
