Sauvegarder une base de données MySQL dans Git est-il une bonne idée?

J'essaie d'améliorer la situation de sauvegarde pour mon application. J'ai une application Django et une 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 bien, 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 effectuera beaucoup de travail supplémentaire en différenciant le dump MySQL à chaque commit, ce qui n’est pas vraiment nécessaire. Si je compresse le fichier avant de le stocker, git continuera-t-il à les différer?

(Le fichier de vidage est actuellement de 100 Mo non compressé, 5,7 Mo une fois compressé.)

Edit: les définitions de schéma de code et de base de données sont déjà dans Git, ce sont vraiment les données que je crains de sauvegarder maintenant.

Avant de perdre des données, laissez-moi vous présenter une perspective sysadmin à cette question.

Nous créons des sauvegardes pour une seule raison: rendre possible la restauration en cas de problème, comme cela se produira invariablement . En tant que tel, un système de sauvegarde approprié a des exigences qui vont bien au-delà de ce que git peut raisonnablement gérer.

Voici quelques 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". Étant donné que git stocke des objets entiers (bien que compressés), puis les diffère plus tard (par exemple, lorsque vous les 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 ou que vous ne voulez pas. Vous devrez peut-être limiter le nombre ou la durée de conservation des sauvegardes pour économiser de l'espace disque ou pour des raisons juridiques, mais il est difficile de supprimer les anciennes révisions d'un référentiel git sans causer beaucoup de dommages collatéraux.
• La restauration est limitée aux points que vous avez stockés dans le référentiel. Étant donné que les données sont si volumineuses, il peut être long de revenir en arrière plus d'une durée triviale. Un système de sauvegarde conçu à cet effet limite la quantité de données stockées tout en offrant potentiellement davantage de précision et des restaurations plus rapides, ce qui réduit les temps d'arrêt en cas de sinistre. Les solutions de sauvegarde basées sur une base de données ( exemple ) peuvent également fournir une sauvegarde continue , garantissant qu'aucune transaction n'est perdue.
• Les commits sont également susceptibles d'être lents et ralentissent à mesure que la base de données se développe. Rappelez-vous que git est essentiellement un magasin de données de valeurs-clés mappé sur un système de fichiers et est donc soumis aux caractéristiques de performance du système de fichiers sous-jacent. Il est possible que cette durée dépasse éventuellement l'intervalle de sauvegarde et qu'à ce stade, vous ne puissiez plus respecter votre contrat de niveau de service. De plus, les systèmes de sauvegarde appropriés prennent plus de temps à mesure que les données grandissent, mais pas de façon aussi spectaculaire, car ils gèrent automatiquement leur propre taille en fonction de la stratégie de rétention que vous avez configurée.

Malgré le fait qu'il y a apparemment plusieurs choses intéressantes à faire avec un dump de base de données si vous le mettez dans git, dans l'ensemble, je ne peux pas le recommander pour conserver des sauvegardes. D'autant plus que les systèmes de sauvegarde sont largement disponibles (et beaucoup sont même open source) et permettent de mieux protéger vos données et de permettre une récupération aussi rapide que 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 dans le temps", de sorte que vous pouvez parfaitement utiliser GIT pour quelque chose comme ça, mais cela ne veut pas dire que vous devriez . GIT est conçu pour stocker le code source, de sorte que vous manqueriez de la plupart de ses fonctionnalités et que vous échangeriez beaucoup de performances pour un peu de commodité.

Laissez-moi supposer que la raison principale pour laquelle vous pensez à cela est de "conserver une copie des données et du code synchronisés", ce qui signifie que vous craignez que la version 2.0 de votre code nécessite un schéma de base de données différent de celui de la version 1.0. . Une solution plus simple consisterait à stocker le schéma de base de données, sous la forme d'un ensemble de scripts SQL avec des CREATEinstructions, le long du code source de votre référentiel Git. Ensuite, une partie de votre procédure d’installation consiste à exécuter ces scripts sur un serveur de base de données précédemment installé.

Le contenu réel de ces CREATEtables -d n'a 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 sociétés par différentes équipes. Après quelques semaines, le contenu des tables sera très différent, même si les schémas sont exactement les mêmes.

Puisque vous voulez sauvegarder le contenu de la base de données, je vous suggère d'utiliser un script de sauvegarde qui balise le cliché de sauvegarde avec la version actuelle du logiciel auquel le cliché appartient. Le script doit figurer dans le référentiel GIT (pour pouvoir accéder à 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.

EDIT :

Après avoir lu le message original qui a motivé la question , je trouve cette idée encore plus douteuse. Le point clé est que la mysqldumpcommande transforme l'état actuel d'une base de données en une série d' INSERTinstructions SQL , et que GIT puisse les différencier pour obtenir uniquement les lignes de table mises à jour.

La mysqldumppartie est saine, car c'est l' une des méthodes de sauvegarde listées dans la documentation de MySQL. La partie GIT est l'endroit où l'auteur ne parvient pas à remarquer que les serveurs de base de données conservent un journal des transactions afin de récupérer des pannes, y compris MySQL . C'est en utilisant ce journal , et non GIT, que vous devez créer des sauvegardes incrémentielles pour votre base de données. Cela présente avant tout l’avantage de pouvoir faire pivoter ou vider les journaux après la récupération, au lieu de gonfler un référentiel GIT à l’infini et au-delà ...

Personnellement, je ne pense pas que ce soit une bonne idée d’utiliser un système 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 sauvegarde MySQL. Le fait que vous puissiez le faire ne signifie pas automatiquement que vous devriez le faire. De plus, votre référentiel, qui envisage une nouvelle sauvegarde de base de données pour chaque nouvelle validation, augmentera considérablement, en utilisant beaucoup d'espace disque et les performances de GIT seront affectées, ce qui ralentira le système de contrôle de source. Pour moi, il n’est pas difficile d’exécuter une stratégie de sauvegarde et de toujours préparer un fichier de sauvegarde lorsque vous devez restaurer la base de données lorsque quelque chose ne va pas dans votre code, mais que 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 dans le stockage des fichiers de sauvegarde pour le jour 1 et pour le jour 2, puis pour voir les différences entre les deux fichiers de sauvegarde. Cela nécessitera beaucoup de travail supplémentaire et inutile. Au lieu d’utiliser GIT pour stocker les sauvegardes de la base de données lorsque vous validez du nouveau code, stockez les sauvegardes de la base de données dans un chemin différent, séparées par la date et l’heure, et insérez dans votre code une référence aux nouvelles sauvegardes de la 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 note 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 car certaines données ont été perdues, n'a pas besoin de 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 quelle est la dernier fichier de sauvegarde qui lui permettra de restaurer la base de données, sans erreur ni perte de données, réduisant ainsi 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 le plus rapidement possible, lorsque le système échoue pour certaines raisons. Si vous stockez les sauvegardes de la base de données dans GIT, liées à vos validations, vous n'autorisez pas l'administrateur de la base de données à restaurer les données rapidement, car vos sauvegardes sont limitées aux instants que vous avez stockés dans le référentiel GIT et à réduire les temps d'arrêt. du système,

Ensuite, je ne recommande pas de stocker les sauvegardes à l’aide de GIT, mais d’utiliser une bonne solution logicielle de sauvegarde (il en existe certaines ici ), qui offrira une plus grande granularité et vous permettra de conserver vos données en toute sécurité. récupération de données simple et rapide en cas de sinistre.

Vous ne devez pas stocker de données binaires dans Git, en particulier une base de données.
Les modifications de code et les modifications de base de données DML sont des choses totalement différentes.

MySQL et Oracle peuvent écrire des journaux d'archivage dans le but d'être restaurés à tout moment. Il suffit de sauvegarder 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 des sauvegardes complètes régulières. En outre, il est inutile de les mettre dans git - ceux-ci sont déjà un référentiel dans un sens.