La sauvegarde d'une base de données MySQL dans Git est-elle une bonne idée?
J'essaie d'améliorer la situation de sauvegarde de mon application. J'ai une Django et base de données MySQL. J'ai lu un article suggérant de sauvegarder la base de données dans Git.
D'une part, je l'aime, car il gardera une copie des données et du code synchronisés.
Mais Git est conçu pour le code, pas pour les données. En tant que tel, il fera beaucoup de travail supplémentaire en différant le vidage MySQL à chaque validation, ce qui n'est pas vraiment nécessaire. Si je compresse le fichier avant de le stocker, git differa-t-il toujours les fichiers?
(Le fichier de vidage est actuellement de 100 Mo non compressé, 5,7 Mo lorsqu'il est compressé.)
Edit: les définitions de code et de schéma de base de données sont déjà dans Git, ce sont vraiment les données que je souhaite sauvegarder maintenant.
Avant de perdre des données, permettez-moi d'essayer de présenter une perspective sysadmin à cette question.
Il n'y a qu'une seule raison pour laquelle nous créons des sauvegardes: pour permettre la restauration en cas de problème, comme cela invariablement le sera. En tant que tel, n système de sauvegarde approprié a des exigences qui vont bien au-delà de ce que git peut raisonnablement gérer.
Voici quelques-uns des problèmes que je peux prévoir en essayant de sauvegarder votre base de données dans git:
- Le référentiel augmentera considérablement à chaque "sauvegarde". Puisque git stocke des objets entiers (bien que compressés) puis diffère les plus tard (par exemple lorsque vous exécutez
git gc) , et conserve l'historique pour toujours , vous aurez une très grande quantité de données stockées dont vous n'avez pas réellement besoin ni même envie . Vous devrez peut-être limiter la quantité ou la période de rétention des sauvegardes que vous effectuez pour économiser de l'espace disque ou pour des raisons juridiques, mais il est difficile de supprimer anciennes révisions d'un dépôt git sans beaucoup de dommages collatéraux. - La restauration est limitée aux points dans le temps que vous avez stockés dans le référentiel, et comme les données sont si volumineuses, revenir en arrière plus d'une période triviale peut être lent. Un système de sauvegarde conçu à cet effet limite la quantité de données stockées tout en offrant potentiellement plus de granularité et fournit des restaurations plus rapides, réduisant les temps d'arrêt en cas de sinistre. Les solutions de sauvegarde basées sur la base de données ( exemple ) peuvent également fournir une sauvegarde continue , garantissant ainsi qu'aucune transaction n'est perdue.
- Les validations sont également susceptibles d'être lentes et de ralentir à mesure que la base de données se développe. N'oubliez pas que git est essentiellement n magasin de données de valeurs-clés mappé sur un système de fichiers , et est donc soumis aux caractéristiques de performances du système de fichiers sous-jacent. Il est possible que cette durée dépasse éventuellement l'intervalle de sauvegarde, et à ce stade, vous ne pouvez plus respecter votre SLA. Les systèmes de sauvegarde appropriés prennent également plus de temps à sauvegarder à mesure que les données augmentent, mais pas de manière spectaculaire, car ils géreront automatiquement leur propre taille en fonction de la politique de rétention que vous aurez configurée.
Malgré le fait qu'il y ait apparemment plusieurs choses intéressantes vous pouvez faire un vidage de base de données si vous le mettez dans git, dans l'ensemble je ne peux pas le recommander dans le but de garder des sauvegardes. D'autant plus que les systèmes de sauvegarde sont largement disponibles (et beaucoup sont même open source) et fonctionnent beaucoup mieux pour garder vos données en sécurité et permettre de récupérer le plus rapidement possible.
Mes deux cents: je ne pense pas que ce soit une bonne idée. GIT fait quelque chose comme "stocker des instantanés d'un ensemble de fichiers à différents moments", donc vous pouvez utiliser parfaitement GIT pour quelque chose comme ça, mais cela ne signifie pas que vous devrait. GIT est conçu pour stocker le code source, de sorte que vous manquez la plupart de ses fonctionnalités et que vous échangez beaucoup de performances pour un peu de commodité.
Permettez-moi de supposer que la principale raison pour laquelle vous songez à cela est de "conserver une copie des données et du code synchronisés", et que cela signifie que vous craignez que la version 2.0 de votre code ait besoin d'un schéma de base de données différent de la version 1.0. . Une solution plus simple serait de stocker le schéma de la base de données, sous la forme d'un ensemble de scripts SQL avec des instructions CREATE, le long du code source dans votre référentiel Git. Ensuite, une partie de votre procédure d'installation consisterait à exécuter ces scripts sur un serveur de base de données précédemment installé.
Les véritables contenus de ces seules tables CREATE - d n'ont rien à voir avec la version de votre code source. Imaginez que vous installiez votre logiciel, version 1.0, sur le serveur A et sur le serveur B, qui sont utilisés dans différentes entreprises par différentes équipes. Après quelques semaines, le contenu des tableaux sera très différent, même si les schémas sont exactement les mêmes.
Puisque vous souhaitez sauvegarder le contenu de la base de données, je vous suggère d'utiliser un script de sauvegarde qui balises le vidage de sauvegarde avec la version actuelle du logiciel auquel le vidage appartient. Le script doit être dans le référentiel GIT (afin qu'il ait accès à la chaîne de version du code source), mais les vidages eux-mêmes n'appartiennent pas à un système de contrôle de version.
[~ # ~] éditez [~ # ~] :
Après avoir lu le message original qui a motivé la question , je trouve que c'est une idée encore plus douteuse. Le point clé est que la commande mysqldump transforme l'état actuel d'une base de données en une série d'instructions SQL INSERT, et GIT peut les différencier pour obtenir uniquement les lignes de table mises à jour.
La partie mysqldump est saine, car elle est l'une des méthodes de sauvegarde répertoriée dans la documentation de MySQL. La partie GIT est l'endroit où l'auteur ne remarque pas que les serveurs de base de données conservent un journal des transactions afin de récupérer des plantages, y compris MySQL . C'est en utilisant ce journal , pas GIT, que vous devez créer des sauvegardes incrémentielles pour votre base de données. Cela a, avant tout, l'avantage que vous pouvez faire pivoter ou vider les journaux après la récupération, au lieu de gonfler un référentiel GIT dans l'infini et au-delà ...
Personnellement, je ne pense pas que ce soit une bonne idée d'utiliser un système de version de contrôle de source pour stocker les fichiers de sauvegarde, car le contrôle de version GIT est conçu pour les fichiers de données, pas pour les fichiers binaires ou les fichiers de vidage comme un fichier de vidage de sauvegarde MySQL. Le fait que vous pouvez le faire ne signifie pas automatiquement que vous devriez le faire. De plus, votre référentiel, compte tenu d'une nouvelle sauvegarde de base de données pour chaque nouvelle validation, augmentera considérablement, en utilisant beaucoup d'espace sur le disque dur et les performances de GIT seront affectées, entraînant un système de contrôle de source lent. Pour moi, il est bien d'exécuter une stratégie de sauvegarde et d'avoir toujours prêt un fichier de sauvegarde lorsque vous devez restaurer la base de données lorsqu'un problème dans votre code ne fonctionne pas, mais les outils de contrôle de source ne sont pas conçus pour stocker des données binaires.
Pour ces raisons, je ne vois aucun utilitaire pour stocker les fichiers de sauvegarde pour le jour 1 et pour le jour 2, puis voir les différences entre les deux fichiers de sauvegarde. Cela demandera beaucoup de travail supplémentaire et inutile. Au lieu d'utiliser GIT pour stocker des sauvegardes de base de données lorsque vous validez un nouveau code, stockez les sauvegardes de base de données dans un chemin différent, séparé par date et heure, et insérez dans votre code une référence aux nouvelles sauvegardes de base de données créées pour chaque version, à l'aide des balises, comme quelqu'un l'a déjà suggéré.
Ma dernière remarque sur les sauvegardes de base de données et GIT : Un administrateur de base de données, lorsqu'il a besoin de restaurer une base de données parce que certaines données ont été perdues, n'a pas besoin pour vérifier les différences entre le fichier de sauvegarde pour le jour 1 et le fichier de sauvegarde pour le jour 2, il a juste besoin de savoir quel est le dernier fichier de sauvegarde qui lui permettra de restaurer la base de données, sans aucune erreur et perte de données, réduisant les temps d'arrêt. En effet, la tâche d'un administrateur de base de données est de rendre les données disponibles pour la récupération dès que possible, lorsque le système, pour certaines raisons, échoue. Si vous stockez les sauvegardes de base de données dans GIT, liées à vos validations, vous ne permettez pas à l'administrateur de base de données de restaurer les données rapidement, car vos sauvegardes sont limitées aux points dans le temps que vous avez stockés dans le référentiel GIT, et de réduire les temps d'arrêt du système, car les performances de votre référentiel GIT seront considérablement réduites, car vous aurez beaucoup de données à stocker.
Ensuite, je ne recommande pas de stocker les sauvegardes à l'aide de GIT, utilisez plutôt une bonne solution logicielle de sauvegarde (il y en a --- ici ), qui fournira plus de granularité et vous permettra de conserver vos données sûr et sécurisé, et rendre votre récupération de données simple et rapide en cas de catastrophe.
Vous ne devez pas stocker de données binaires dans Git - en particulier la base de données.
Les changements de code et les changements de base de données DML sont des choses totalement différentes.
MySQL et Oracle peuvent écrire des journaux d'archives dans le but d'être restaurés à tout moment. Sauvegardez simplement ces journaux dans un endroit sûr et tout ira bien.
Utiliser Git pour sauvegarder ces "journaux d'archivage" n'a pas de sens. Les journaux d'archivage dans les environnements de production sont plutôt lourds et doivent être supprimés après avoir effectué des sauvegardes complètes régulières. Il est également inutile de les mettre dans git - ceux-ci sont déjà un dépôt dans un certain sens.