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

57

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.

wobbily_col
la source
13
Si votre entreprise dispose d’un service informatique (ops), il devrait en assurer la gestion.
Michael Hampton
1
les données font-elles partie de l'application ou qu'est-ce qui est créé via l'application?
Winston Ewert
1
Git essaiera de différencier tous les fichiers lors de l’exécution git gc(ou le sous-jacent git repack; par défaut, il sera automatiquement exécuté automatiquement). Cela les dégonfle toujours , il serait donc peut-être préférable de les stocker non compressés.
Jan Hudec
1
De quel type de base de données s'agit-il: s'agit-il d'une base de données de production ou de développement?
el.pescado
6
viget.com/extend/backup-your-database-in-git , il est un "développeur senior".
wobbily_col

Réponses:

101

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.

Michael Hampton
la source
C'est la meilleure réponse car Michael a couvert les problèmes de cohérence. En fonction de la taille et de l'utilisation de la base de données, un instantané ne peut pas reproduire de manière fiable les données à un moment donné et vous risquez de rencontrer des problèmes de contrainte. La réplication est peut-être quelque chose que vous souhaitez examiner - dev.mysql.com/doc/refman/5.0/en/replication.html
Aaron Newton
4
Ce n'est pas simplement la meilleure réponse, c'est la seule réponse. En règle générale, vous êtes un développeur, les sauvegardes ne sont donc pas votre métier. quelqu'un d'autre s'en occupe (ou devrait le faire) déjà, et si vous commencez à vous impliquer, vous risquez d'interférer avec un système qui fonctionne déjà. Ces boîtes doivent déjà être sauvegardées. Vous disposerez ainsi d'une sauvegarde, de votre propre sauvegarde et d'une sauvegarde de votre propre sauvegarde, le tout avec une taille de plus en plus grande. C'est juste des noix. De plus, vous êtes développeur: pourquoi vous approchez-vous (probablement) de toute façon de production?
Maximus Minimus
2
@JimmyShelter Il y a une école de pensée que cela signifie de Devops pas que Dev et Ops travaillent en étroite collaboration, mais que Dev fait ne Ops. Cela ne fonctionne généralement pas bien, mais cela n'empêche pas les gens de l'essayer.
Michael Hampton
Cela devrait être la réponse acceptée. Il explique clairement les exigences et le but d'un système de sauvegarde, puis montre comment git ne convient pas. Points bonus supplémentaires pour la discussion sur la cohérence et la performance.
Gabriel Bauman
Je tiens à dire que j’ai posté ma réponse en supposant que le PO ne dispose d’aucune équipe chargée des opérations qui ne puisse gérer ce problème pour lui. Je conviens avec vous qu'il est préférable de laisser ce type de tâche à ceux qui gèrent réellement le système et qui savent comment s'y prendre. Mais il y a des situations où vous devez mettre un chapeau qui n'est pas tout à fait le vôtre, et je crois que dans cette situation, il est préférable d'essayer d'apprendre quelques bonnes pratiques que de simplement proposer votre propre solution artificielle. Je dois dire que j'ai également trouvé votre réponse très instructive!
logc
39

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à ...

logc
la source
2
Je ne suis pas sûr de voir un quelconque intérêt à stocker le schéma de base de données sans les données dans le contrôle de version. Les données sont la chose la plus importante et c'est ce que je veux sauvegarder. J'aime l'idée de marquer la sauvegarde de la base de données avec la version actuelle du logiciel. Je vais essayer de mettre en œuvre quelque chose comme ça.
wobbily_col
10
Le point de stocker le schéma sans les données est que, juste après l'installation, votre logiciel doit être "prêt à être utilisé". Si c'est un wiki, alors il devrait être prêt à commencer à créer des pages de wiki et à y écrire quelque chose. Si vous installez le schéma et le contenu, votre wiki est déjà rempli de pages wiki X après l'installation ... Ce n'est pas exactement "installer un système wiki pour écrire notre contenu", mais "copier un wiki quelque part pour le lire" .
logc
3
Il peut être judicieux de modifier votre question en fonction de la situation dans laquelle vous vous trouvez. Même si vous ne pouvez pas publier tous les détails, il serait important d'indiquer que vous avez besoin de conserver un grand nombre de données sans modification dans chaque installation, ou il y a une seule installation ...
logc
2
@wobbily_col Un format non textuel et binaire a une valeur limitée dans le contexte du contrôle de source. Vous ne pouvez pas le différencier , vous ne pouvez pas le brancher / le fusionner , etc. Ainsi, bien que vous puissiez certainement utiliser git pour stocker la base de données, la plupart des gens préfèrent créer un script pour la structure de la base de données ainsi que pour les données nécessaires. C'est un compromis entre avoir un peu plus de travail et fournir la liste de fonctionnalités ci-dessus. Vous devrez déterminer si c'est une bonne idée pour votre solution. Sinon, vous pouvez probablement demander à GIT de stocker directement la base de données, ce n'est tout simplement pas la solution la mieux adaptée à la tâche.
Daniel B
3
@RaduMurzea: Je pense que c'est une question de principes. Un système de contrôle de version est conçu pour gérer le code source, et non les fichiers binaires, c'est tout. Ce n'est pas une question de taille. Non, les sauvegardes de base de données ne doivent pas être archivées dans le référentiel, tout comme les vidéos de formation ne doivent pas être archivées. Mais personne ne vous en empêche. :)
logc
7

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.

Alberto Solano
la source
Peut-être que le votant inférieur expliquera pourquoi il / elle a voté contre ..
Alberto Solano
1
Pas les votants, mais je pense que cette approche introduit un conflit de fusion toujours présent qui n'est pas particulièrement propice au flux de travail de branche souvent utilisé par la fusion que la plupart des utilisateurs git préfèrent.
Daniel B
@DanielB Je propose de ne pas utiliser le système de contrôle de version pour stocker les fichiers de sauvegarde de la base de données. Je pense que le problème de sauvegarde de base de données pourrait être facilement résolu sans utiliser aucun système de contrôle de version. Les systèmes de contrôle de version (GIT, TFS, SVN, etc.) sont conçus pour les logiciels, pas pour les sauvegardes de fichiers ou les sauvegardes de bases de données, ni pour le stockage de données (il existe de nombreuses solutions pour cela).
Alberto Solano
Je pense que la plupart des utilisateurs lisent les premières phrases et les votes négatifs, car il semble que vous allez dire que vous pouvez l'utiliser.
1
@ AlbertoSolano je vois; mais en lisant la question ("puis-je sauvegarder ma base de données dans GIT?") et ensuite votre première déclaration ("c'est bien de stocker le fichier de sauvegarde ..."), il semble que vous disiez le contraire. Le reste de la réponse semble dire que ce n'est ni ici ni là-bas, alors que je soupçonne la plupart des gens de penser que c'est un accident de train qui attend de se produire.
Daniel B
1

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.

Jehy
la source
1
pourquoi ne pas utiliser Git pour sauvegarder ces "journaux d'archivage" créés par MySQL?
moucher
1
Juste parce que ça 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. De plus, il est inutile de les mettre dans git - ceux-ci sont déjà un référentiel dans un sens. Michael Hampton donne une très bonne réponse sur cette question (sur cette page).
Jehy
1
Pourquoi s'embêter à faire tourner les bûches, si vous allez conserver une copie de tout dans git? Vous pourriez aussi bien garder un seul fichier journal de monstre.
wobbily_col