Les systèmes de base de données ont la responsabilité de stocker et d'assurer une disponibilité constante des données pertinentes chaque fois que nécessaire à tout moment de l'exploitation. La plupart des entreprises ne parviennent pas à poursuivre leurs activités après des cas de perte de données à la suite d'une défaillance de la base de données, d'un pont de sécurité, d'une erreur humaine ou d'une défaillance catastrophique pouvant détruire complètement les nœuds d'exploitation en production. Garder les bases de données dans le même centre de données expose à un risque élevé de perdre toutes les données en cas de ces outrages.
La réplication et la sauvegarde sont les moyens couramment utilisés pour garantir une haute disponibilité des données. La sélection entre les deux dépend de la fréquence à laquelle les données changent. La sauvegarde est préférable lorsque les données ne changent pas plus fréquemment et que l'on ne s'attend pas à avoir autant de fichiers de sauvegarde. D'un autre côté, la réplication est préférée pour les données qui changent fréquemment en plus de certains autres avantages associés, comme le service de données à un emplacement spécifique en réduisant la latence des requêtes. Cependant, la réplication et la sauvegarde peuvent être utilisées pour une intégrité et une cohérence maximales des données lors de la restauration en cas d'échec.
Les sauvegardes de base de données présentent plus d'avantages en plus de fournir un point de restauration pour fournir les bases pour créer de nouveaux environnements pour le développement, l'accès ouvert et la mise en scène sans tempérer avec la production. L'équipe de développement peut rapidement et facilement tester les nouvelles fonctionnalités intégrées et accélérer leur développement. Les sauvegardes peuvent également être utilisées pour le point de contrôle des erreurs de code lorsque les données résultantes ne sont pas cohérentes.
Considérations relatives à la sauvegarde de MongoDB
Les sauvegardes sont créées à certains moments pour refléter (agissant comme un instantané de la base de données) quelles données la base de données héberge à ce moment donné. Si la base de données échoue à un moment donné, nous pouvons utiliser le dernier fichier de sauvegarde pour restaurer la base de données à un point antérieur à son échec. Cependant, il faut prendre en considération certains facteurs avant de procéder à une récupération, notamment :
- Objectif de point de récupération
- Objectif de temps de récupération
- Isolation des bases de données et des instantanés
- Complications avec le sharding
- Processus de restauration
- Facteurs de performances et stockage disponible
- Flexibilité
- Complexité du déploiement
Objectif de point de récupération
Ceci est effectué afin de déterminer la quantité de données que vous êtes prêt à perdre pendant le processus de sauvegarde et de restauration. Par exemple, si nous avons des données utilisateur et des données de flux de clics, les données utilisateur auront la priorité sur les analyses de flux de clics car ces dernières peuvent être régénérées en surveillant les opérations dans votre application après la restauration. Une sauvegarde continue doit être privilégiée pour les données critiques telles que les informations bancaires, les données de l'industrie de production et les informations des systèmes de communication et doit être effectuée à intervalles rapprochés. Si les données ne changent pas fréquemment, il peut être moins coûteux d'en perdre une grande partie si vous faites un instantané restauré par exemple 6 mois ou 1 an plus tôt.
Objectif de temps de récupération
Il s'agit d'analyser et de déterminer la rapidité avec laquelle l'opération de restauration peut être effectuée. Pendant la récupération, vos applications subiront des temps d'arrêt qui sont également directement proportionnels à la quantité de données qui doivent être récupérées. Si vous restaurez un grand nombre de données, cela prendra plus de temps.
Isolation des bases de données et des instantanés
L'isolement est une mesure de la proximité des instantanés de sauvegarde par rapport aux serveurs de base de données principaux en termes de configuration logique et physique. S'ils sont suffisamment proches, le temps de récupération diminue au détriment d'une probabilité accrue d'être détruit en même temps que la base de données est détruite. Il n'est pas conseillé d'héberger les sauvegardes et l'environnement de production dans le même système afin d'éviter que toute perturbation sur les serveurs ne s'atténue également sur les sauvegardes.
Complications avec le partage
Pour un système de base de données distribué via le partitionnement, une certaine complexité de sauvegarde est présentée et les activités d'écriture peuvent devoir être interrompues sur l'ensemble du système. Différents fragments termineront différents types de sauvegardes à des moments différents. Compte tenu des sauvegardes logiques et des sauvegardes Snapshot,
Sauvegardes logiques
- Les fragments sont de tailles différentes et se termineront donc à des moments différents
- Les vidages de base de MongoDB ignoreront le --oplog et ne seront donc pas cohérents sur chaque partition.
- L'équilibreur peut être désactivé alors qu'il est censé être activé simplement parce que certaines partitions n'ont peut-être pas terminé le processus de restauration
Sauvegardes d'instantanés
- Fonctionne bien pour une seule réplique à partir des versions 3.2 et ultérieures. Vous devriez donc envisager de mettre à jour votre version de MongoDB.
Processus de restauration
Certaines personnes effectuent des sauvegardes sans tester si elles fonctionneront en cas de restauration. Une sauvegarde consiste essentiellement à fournir une capacité de restauration, sinon elle deviendra inutile. Vous devriez toujours essayer d'exécuter les sauvegardes sur différents serveurs de test pour voir si elles fonctionnent.
Facteurs de performances et stockage disponible
Les sauvegardes ont également tendance à prendre de nombreuses tailles comme les données de la base de données elle-même et doivent être suffisamment compressées pour ne pas occuper beaucoup d'espace inutile qui pourrait réduire les ressources de stockage globales du système. Ils peuvent être archivés dans des fichiers zip, réduisant ainsi leur taille globale. De plus, comme mentionné précédemment, on peut archiver les sauvegardes dans différents centres de données à partir de la base de données elle-même.
Les sauvegardes peuvent déterminer différentes performances de la base de données dans la mesure où certaines pourraient la dégrader. Dans ce cas, les sauvegardes continues entraîneront un certain recul et doivent donc être converties en sauvegardes planifiées pour éviter l'épuisement des fenêtres de maintenance. Dans la plupart des cas, des serveurs secondaires sont déployés pour prendre en charge les sauvegardes. Dans ce cas :
- Les nœuds uniques ne peuvent pas être sauvegardés de manière cohérente car MongoDB utilise la lecture non validée sans oplog lors de l'utilisation de la commande mongodump et dans ce cas, les sauvegardes ne seront pas sécurisées.
- Utilisez des nœuds secondaires pour les sauvegardes car le processus lui-même prend du temps en fonction de la quantité de données impliquées et les applications connectées subiront des temps d'arrêt. Si vous utilisez le primaire qui doit également mettre à jour les Oplogs, vous risquez de perdre des données pendant ce temps d'arrêt
- Le processus de restauration prend beaucoup de temps, mais les ressources de stockage affectées sont minuscules.
Flexibilité
Plusieurs fois, vous pouvez ne pas vouloir certaines données pendant la sauvegarde, comme dans l'exemple de l'objectif de point de récupération, on peut vouloir que la récupération soit effectuée et filtrer les données des clics de l'utilisateur. Pour ce faire, vous avez besoin d'une stratégie de sauvegarde partielle qui offrira la flexibilité de filtrer les données qui ne vous intéressent pas, réduisant ainsi la durée de la récupération et les ressources qui auraient été gaspillées. La sauvegarde incrémentielle peut également être utile pour que seules les parties de données qui ont changé soient sauvegardées à partir du dernier instantané plutôt que de prendre des sauvegardes entières pour chaque instantané.
Complexité du déploiement
Votre stratégie de sauvegarde doit être facile à définir et à maintenir dans le temps. Vous pouvez également programmer vos sauvegardes afin de ne pas avoir à les faire manuellement quand vous le souhaitez.
Conclusion
Les systèmes de base de données garantissent la "vie après la mort" si seulement un système de sauvegarde bien établi est en place. La base de données pourrait être détruite par des facteurs catastrophiques, une erreur humaine ou des attaques de sécurité pouvant entraîner la perte ou la corruption de données. Avant de faire une sauvegarde, il faut considérer le type de données en termes de taille et d'importance. Il est toujours déconseillé de conserver vos sauvegardes dans le même centre de données que votre base de données afin de réduire la probabilité que les sauvegardes soient détruites simultanément. Les sauvegardes peuvent altérer les performances de la base de données, il faut donc faire attention à la stratégie à utiliser et au moment d'effectuer la sauvegarde. N'effectuez pas vos sauvegardes sur le nœud principal car cela pourrait entraîner une indisponibilité du système pendant la sauvegarde et par conséquent une perte de données importantes.
