Comment puis-je mettre une base de données sous git (contrôle de version)?
Je suis en train de faire une application web, et j'ai besoin de faire une branche des changements majeurs, la chose est, ces changements nécessitent des modifications au schéma de base de données, donc je voudrais mettre l'ensemble de la base de données sous git en tant que bien.
Comment dois-je faire? est-il un dossier spécifique que je peux garder en vertu d'un dépôt git? Comment puis-je savoir laquelle? Comment puis-je être sûr que je suis en train de mettre le bon dossier?
J'ai besoin d'être sûr, parce que ces changements ne sont pas compatibles; je ne peux pas se permettre de visser.
La base de données dans mon cas, c'est PostgreSQL
Edit:
Quelqu'un a suggéré de prendre des sauvegardes et de mettre le fichier de sauvegarde sous contrôle de version à la place de la base de données. Pour être honnête, je trouve cela vraiment difficile à avaler.
Il y a une meilleure façon.
Mise à jour:
OK, donc il ya pas de meilleure façon, mais je ne suis pas encore tout à fait convaincu, donc je vais un peu changer ma question:
J'aimerais mettre l'ensemble de la base de données sous contrôle de version, ce moteur de base de données puis-je utiliser afin que je puisse mettre la base de données sous contrôle de version à la place de son dump?
Serait sqlite être git de l'environnement?
Depuis ce n'est que l'environnement de développement, je peux choisir la base de données que je veux.
Edit2:
Ce que je veux vraiment, c'est de ne pas suivre mon évolution de l'histoire, mais pour être en mesure de passer de mon "nouveaux changements radicaux" de la branche de l'actuel "branche stable" et être en mesure, par exemple pour corriger quelques bugs/problèmes, etc, avec la branche stable. Tels que, lorsque je change de branches, la base de données de l'auto-magiquement devient compatible avec la branche, je suis actuellement sur.
Je n'ai pas vraiment beaucoup de soins sur les données réelles.
- Pour être honnête, je viens de faire des copies de la base de données si je suis en introduisant des modifications de schéma et d'avoir à traiter avec de multiples branches de développement en même temps... dev bases de données devrait être assez petit pour le faire. J'avais l'égard de tout système qui a essayé d'être intelligent et faire DB changements juste parce que j'ai changé de branche source avec suspicion. Et j'aimerais aussi être sûr que les choses continuer à travailler, si j'ai tout simplement cloné mon espace de travail et avait une branche en un seul endroit, et l'autre dans le nouveau.
- Voir aussi le git base de l'outil de sauvegarde
bup - Si vous considérez le script (et ses composantes) à l'initialisation de votre base de données comme un artefact sous contrôle de version, puis 'sauvegardes' peut ne pas sembler une mauvaise chose. Si vous modifiez votre base de données de schéma dans une radical de direction, vous avez besoin de mettre à jour le script que inits la base de données avec les données.
- La caisse de ma réponse, pour un logiciel qui fait ça exactement : stackoverflow.com/a/28123546/1662984
- Voir: Klonio - base de données distribuée versioning
- liquibase.org ?
- Gros fichiers binaires (comme les fichiers de base de données) ne fonctionnent pas bien avec git. Vous pouvez le faire facilement si, juste être sûr de vérifier que git n'est pas d'essayer de corriger les fins de ligne
- Résumé des options pour la version de base de données de contrôle - nombreuses et spécifiques à PostgreSQL: stackoverflow.com/questions/846659/...
Vous devez vous connecter pour publier un commentaire.
Prendre un vidage de base de données, et le contrôle de version à la place. De cette façon, c'est un fichier de texte plat.
Personnellement, je vous suggère de garder à la fois un vidage des données, et un schéma de vidage. De cette façon, à l'aide de diff, il devient assez facile de voir ce qui a changé dans le schéma de la révision de la révision.
Si vous faire de gros changements, vous devriez avoir une base de données secondaire que vous faites de nouvelles modifications de schéma et de ne pas toucher à l'ancien car comme vous l'avez dit vous faites une branche.
Découvrez la Refactorisation de Bases de données (http://databaserefactoring.com/) pour un tas de bonnes techniques pour la maintenance de votre base de données en tandem avec les changements de code.
Il suffit de dire que vous vous posez les mauvaises questions. Au lieu de mettre votre base de données dans le dépôt git, vous devriez être en décomposition vos modifications en petits vérifiables étapes, de sorte que vous pouvez migrer/annulation des modifications de schéma avec facilité.
Si vous voulez avoir la pleine capacité de récupération, vous devriez envisager l'archivage de vos postgres WAL journaux et utiliser le PITR (point dans le temps de récupération) pour lire/opérations de change à terme spécifiques connu un bon état.
Je commence à penser que d'une solution simple, ne sais pas pourquoi je n'avais pas pensé avant!!
De cette façon, je peux passer des branches sans se soucier de la base de données des modifications de schéma.
EDIT:
En double exemplaire, je veux créer une autre base de données avec un nom différent (comme
my_db_2); ne pas faire un dump ou quelque chose comme ça.Utiliser quelque chose comme LiquiBase cela vous permet de garder le contrôle de révision de votre Liquibase fichiers. vous pouvez marquer les changements de production, et ont lb garder votre base de données à jour, soit de production ou de développement, (ou quel que soit le schéma que vous voulez).
Il y a un grand projet intitulé Migrations en vertu de la Doctrine qui a construit à cet effet.
Il est toujours en état alpha et construit pour php.
http://docs.doctrine-project.org/projects/doctrine-migrations/en/latest/index.html
Face à un besoin similaire et voici ce que mes recherches sur la base de données de systèmes de contrôle de version de vomir:
https://github.com/cbbrowne/mahout
L'auteur propose un guide ici: https://www.depesz.com/2010/08/22/versioning/
https://www.red-gate.com/products/sql-development/sql-change-automation/
ChronicDBainsi:ChronicDB provides dynamic database upgrades with zero database downtime and inconsistencies.crunchbase.com/organization/chronicdb#section-overview Un gars nommé Kristis Makris a été l'un des fondateurs, peut-être connu pour SCMBug: mkgnu.net/scmbugPrendre un coup d'oeil à RedGate SQL Contrôle de code Source.
http://www.red-gate.com/products/sql-development/sql-source-control/
Cet outil est un Serveur SQL server Management Studio snap-in qui vous permettra de placer votre base de données sous Contrôle de code Source avec Git.
C'est un peu cher à $495 par l'utilisateur, mais il y a 28 jours d'essai gratuit disponible.
NOTE
Je ne suis pas affilié à RedGate de quelque façon que ce soit.
Je veux faire quelque chose de similaire, ajouter dans ma base de données des modifications à mon système de contrôle de version.
Je vais suivre les idées dans ce post, de Vladimir Khorikov "La base de données de gestion des versions des meilleures pratiques". En résumé, je vais
Dans le cas où il aide!
Je suis venu à travers cette question, car j'ai un problème similaire, où quelque chose se rapprochant de la base de données d'Annuaire de la structure, les magasins "fichiers", et j'ai besoin de git pour gérer. Elle est distribuée, à travers un nuage, à l'aide de la réplication, c'est le point d'accès se fera via MySQL.
L'essentiel des réponses ci-dessus, semblent à même de suggérer une solution alternative au problème posé, qui manque à l'appel, de l'utilisation de Git pour gérer quelque chose dans une Base de données, donc je vais tenter de répondre à cette question.
Git est un système qui, en essence stocke une base de données de deltas (différences), qui peut être remonté dans l'ordre, pour reproduire un contexte. L'utilisation normale de git suppose que le contexte est un système de fichiers, et ces deltas sont diff dans le système de fichiers, mais vraiment tout git est, est une base de données hiérarchique de deltas (hiérarchique, parce que dans la plupart des cas, chaque delta est un commit avec au moins 1 des parents, disposées dans un arbre).
Aussi longtemps que vous le pouvez générer un delta, en théorie, git peut stocker. Le problème est normalement git attend le contexte, sur lequel c'est la génération de delta pour être un système de fichiers, et de même, lorsque vous commandez un point dans le git de la hiérarchie, il s'attend à générer un système de fichiers.
Si vous souhaitez gérer le changement, dans une base de données, vous avez 2 discrètes problèmes, et je voudrais aborder séparément (si j'étais vous). La première est de schéma, la deuxième est de données (bien que dans votre question, vous avez des données d'état n'est pas quelque chose qui vous préoccupe). Un problème que j'ai eu dans le passé, a été un Dev et de Prod de base de données, où les Dev pourrait prendre des changements progressifs du schéma, et ces changements devaient être consignées dans le CVS, et propogated à vivre, avec des ajouts de plusieurs "statique" des tables. Nous n'avons que par le fait d'avoir un 3ème de la base de données, appelée Croisière, qui ne contenait que des données statiques. Le schéma de Dev et de Croisière pourrait être comparé, et nous avons eu un script pour prendre la diff de ces 2 fichiers et de produire un fichier SQL contenant des instructions ALTER, afin de l'appliquer. De même, toutes les nouvelles données, pourrait être distillé un fichier SQL contenant INSÉRER des commandes. Aussi longtemps que les champs et les tables ne sont ajoutés, et jamais supprimé, le processus pourrait automatiser la génération du SQL pour appliquer le delta.
Le mécanisme par lequel git génère des deltas est
diffet le mécanisme par lequel il combine 1 ou plusieurs deltas avec un fichier, est appeléemerge. Si vous pouvez venir avec une méthode de comparaison et de fusion, dans un contexte différent, git devrait fonctionner, mais, comme il a été discuté de vous préférerez peut-être un outil qui le fait pour vous. Ma première pensée en vue de résoudre les qui est-ce https://git-scm.com/book/en/v2/Customizing-Git-Git-Configuration#External-Merge-and-Diff-Tools qui détaille la façon de remplacer git interne de diff et de l'outil de fusion. Je vais mettre à jour cette réponse, comme je l'ai trouver une meilleure solution au problème, mais dans mon cas, je m'attends à seulement à gérer les modifications de données, dans la mesure-en DB en fonction filestore peut changer, donc ma solution peut ne pas être exactement ce dont vous avez besoin.Vous ne pouvez pas le faire sans l'atomicité, et vous ne pouvez pas obtenir l'atomicité sans l'aide de pg_dump ou une instantanés de système de fichiers.
Mon postgres instance est sur zfs, qui, je l'instantané de temps en temps. C'est environ instantanée et uniforme.
Ce que vous voulez, dans l'esprit, est peut-être quelque chose comme Post Facto, qui stocke les versions de base de données dans une base de données. Cochez cette présentation.
Le projet, apparemment, n'a jamais vraiment allé n'importe où, donc il ne sera probablement pas vous aider immédiatement, mais c'est un concept intéressant. J'ai peur que cela serait très difficile, parce que même la version 1 aurait pour obtenir tous les détails afin d'avoir les gens font confiance à leurs travaux.
J'ai publié un outil pour sqlite qui fait ce que vous demandez. Il utilise un custom diff pilote en tirant parti de l'sqlite projets de l'outil de sqldiff', Uuid comme clés primaires, et les feuilles hors de l'sqlite rowid. Il est encore en alpha, donc la rétroaction est apprécié.
Postgres et mysql sont plus difficiles, comme les données binaires sont conservés dans des fichiers multiples et peuvent même ne pas être valide si vous avez été en mesure d'instantané.
https://github.com/cannadayr/git-sqlite
Je pense que X-Istence est sur la bonne voie, mais il y a un peu plus d'améliorations que vous pouvez apporter à cette stratégie. Tout d'abord, utilisez:
pour vider les tables, séquences, etc et placez ce fichier sous contrôle de version. Vous allez l'utiliser pour séparer les modifications de compatibilité entre vos branches.
Ensuite, effectuer un vidage des données pour l'ensemble des tables qui contiennent la configuration nécessaire pour votre application de fonctionner (devrait probablement passer les données de l'utilisateur, etc), comme formulaire par défaut et d'autres données non modifiable par l'utilisateur de données. Vous pouvez le faire de manière sélective à l'aide de:
C'est une bonne idée, car l'opération peut être vraiment maladroit lors de votre base de données est de 100 mo+ lorsque l'on fait un plein de vidage des données. Une meilleure idée est de sauvegarder un plus à l'ensemble minimal de données que vous avez besoin de tester votre application. Si vos données par défaut est très grande, si, cela peut poser des problèmes si.
Si vous avez absolument besoin de placer les sauvegardes complètes dans le repo, envisager de le faire dans une branche à l'extérieur de votre arborescence des sources. Un système de sauvegarde externe avec certains de référence pour la mise en correspondance svn rev est probablement le meilleur pour cette même si.
Aussi, je vous conseille d'utiliser le format de texte décharges de plus de binaire à des fins de révision (pour le schéma au moins), car ils sont plus faciles à diff. Vous pouvez toujours les comprimer pour économiser de l'espace avant de vérifier dans.
Enfin, jetez un oeil à la postgres sauvegarde de la documentation si vous ne l'avez pas déjà. La façon dont vous êtes en commentant sur la sauvegarde de la "base de données" plutôt que d'un cliché me fait me demander si vous envisagez de système de fichiers basé sur les sauvegardes (voir la section 23.2 des mises en garde).
Cette question est assez bien répondu, mais je voudrais compléter les X-Istence et Dana le Sain d'esprit, en réponse à une petite suggestion.
Si vous avez besoin de contrôle de révision avec un certain degré de granularité, dire tous les jours, tu pourrais couple le texte de vidage à la fois les tables et le schéma avec un outil comme rdiff-backup qui ne sauvegardes incrémentielles. L'avantage, c'est qu'au lieu de stocker des instantanés de sauvegardes quotidiennes, il vous suffit de stocker les différences de la journée précédente.
Avec ce que vous avez à la fois l'avantage de révision, de contrôle et vous ne perdez pas trop de place.
Dans tous les cas, l'utilisation de git directement sur de gros fichiers plats qui changent très souvent n'est pas une bonne solution. Si votre base de données devient trop gros, git va commencer à avoir quelques problèmes à gérer les fichiers.
Je recommanderais neXtep pour la version contrôle de la base de données, il a obtenu une bonne documentation et les forums qui explique comment installer et les erreurs rencontrées. Je l'ai testé pour postgreSQL 9.1 et 9.3, j'ai été capable de le faire travailler pour 9.1 mais 9,3 il ne semble pas fonctionner.
Ce que je fais dans mes projets personnels est, je stocke l'ensemble de ma base de données à dropbox et puis point de MAMP, WAMP flux de travail pour l'utiliser directement à partir de là.. de Cette façon, la base de données est toujours up-to-date où jamais j'ai besoin de faire de certains pays en développement. Mais c'est juste pour le dev! Les Live sites à l'aide de propre serveur pour que les bien sûr! 🙂
Stockage chaque niveau de la base de données de changements sous contrôle de version git est comme pousser votre ensemble base de données avec chaque commit et restauration l'ensemble de votre base de données avec chaque pull.
Si votre base de données est donc sujette à des changements importants et vous ne pouvez pas se permettre de perdre, vous pouvez simplement mettre à jour votre pre_commit et post_merge crochets.
J'ai fait la même chose avec un de mes projets et vous pouvez trouver les directions ici.
C'est comment je le fais:
Depuis votre avoir de libre choix sur DB type utiliser un filebased DB comme par exemple l'oiseau de feu.
Créer un modèle DB qui a le schéma qui correspond à votre succursale et de le stocker dans votre référentiel.
Lors de l'exécution de votre application par programmation créer une copie de votre modèle de DB, de le stocker quelque part d'autre et juste de travailler avec cette copie.
Cette façon, vous pouvez mettre votre base de données de schéma sous contrôle de version sans les données. Et si vous changez votre schéma, vous avez juste à changer le modèle de DB
Nous avons utilisé pour exécuter un site de réseau social, sur une LAMPE standard de configuration. Nous avons eu un Live server, serveur de Test, et le serveur de Développement, ainsi que les développeurs de machines. Tous ont été gérés à l'aide de GIT.
Sur chaque machine, nous avons eu le PHP les fichiers, mais aussi le service MySQL, et un dossier avec des Images aux utilisateurs de charger. Le serveur Live a grandi pour avoir quelques 100K (!) récurrente des utilisateurs, la sauvegarde a été d'environ 2 go (!), le dossier de l'Image a été quelque 50 GO (!). Par le temps que j'ai quitté, notre serveur était d'atteindre la limite de son CPU, de la Ram, et la plupart de tous, la concurrente net des limites de connexion (Nous avons même compilé notre propre version de pilote de carte réseau pour maximiser le serveur 'lol'). Nous ne pouvions pas (vous ne devez assumer avec votre site web) mettre 2 go de données et de 50 go d'images dans GIT.
Pour gérer tout cela sous GIT facilement, on serait ignorer le binaire dossiers (les dossiers contenant les Images) par l'insertion de ces chemins de dossier de dans .gitignore. Nous avons également eu un dossier appelé SQL à l'extérieur de la documentroot d'Apache chemin. Dans ce dossier SQL, nous mettions nos fichiers SQL de la part des développeurs supplémentaires de comptages (001.florianm.sql, 001.johns.sql, 002.florianm.sql, etc). Ces fichiers SQL a été géré par GIT en tant que bien. Le premier fichier sql serait en effet contenir un grand nombre de DB schéma. Nous n'ajoutons pas de données d'utilisateur dans GIT (par exemple les enregistrements de la table des utilisateurs, ou les commentaires au tableau), mais les données comme les configs ou la topologie ou d'autres données du site, a été maintenu dans les fichiers sql (et donc par GIT). La plupart de ses développeurs (qui sais que le code est meilleur) que de déterminer quoi et ce n'est pas maintenu par GIT en ce qui concerne schéma SQL et des données.
Quand il a obtenu un communiqué de presse, l'administrateur se connecte sur le serveur de dev, fusionne le live de la direction, avec tous les développeurs et nécessaire branches sur le dev de la machine à une mise à jour de la branche, et la poussa vers le serveur de test. Sur le serveur de test, il vérifie si le processus de mise à jour pour le serveur Live est toujours valide, et en succession rapide, les points de tout le trafic d'Apache à un espace réservé du site, crée un dump de la DB, points le répertoire de travail de "live", de "mise à jour", exécute tous les nouveaux fichiers sql dans mysql, et mais redirige le trafic vers le site approprié. Lorsque tous les intervenants sont d'avis après avoir examiné le serveur de test, l'Administrateur a fait la même chose à partir du Test de serveur à serveur Live. Par la suite, il fusionne le live de la direction sur le serveur de production, à la branche master sur l'ensemble des serveurs, et relocalisée toutes les branches vivent. Les développeurs ont été responsables eux-mêmes de rebase leurs branches, mais ils savent généralement ce qu'ils font.
Si il y avait des problèmes sur le serveur de test, par exemple. les fusions avait trop de conflits, le code a été repris (en pointant la branche de retour à la "live") et les fichiers sql n'ont jamais été exécutées. Du moment que les fichiers sql ont été exécutés, cela a été considéré comme une non-réversible action à l'époque. Si les fichiers SQL ne fonctionnaient pas correctement, alors la DB a été restaurée en utilisant le Dump (et les développeurs dit, pour fournir de mauvais testé les fichiers SQL).
Aujourd'hui, nous maintenir à la fois un sql et sql-bas dossier avec les mêmes noms de fichiers, où les développeurs ont pour tester à la fois la mise à niveau de sql fichiers, peuvent être également revues à la baisse. Ce dernier pourrait être exécuté avec un script bash, mais c'est une bonne idée si les yeux de l'homme a gardé le suivi du processus de mise à niveau.
C'est pas génial, mais c'est gérable. Espérons que cela vous donne un aperçu de la vie réelle, pratique, relativement à haute disponibilité du site. Que ce soit un peu dépassé, mais encore suivie.
J'ai été à la recherche pour la même fonction pour Postgres (ou des bases de données SQL en général) pendant un certain temps, mais je n'ai pas trouvé les outils pour être adapté (simple et intuitive) assez. Ceci est probablement dû à la nature binaire de la façon dont les données sont stockées. Klonio sons idéal mais semble morte. Noms DB semble intéressant (
et vivant). Jetez aussi un oeil à Irmin (OCaml avec Git-propriétés).Bien que cela ne répond pas à la question qu'il allait travailler avec Postgres, découvrez la Flur.ee base de données. Il dispose d'un "voyage dans le temps" fonctionnalité qui vous permet d'interroger les données à partir d'un point arbitraire dans le temps. J'imagine qu'il doit être en mesure de travailler avec une "ramification" modèle.
Cette base de données a récemment été développé pour la blockchain-fins. En raison de la nature des blockchains, les données doivent être enregistrées dans des incréments, qui est exactement comment git fonctionne. Ils sont le ciblage d'un open-source de presse en T2 2019.
Utiliser un outil comme iBatis Migrations (manuel, tutoriel vidéo) qui vous permet de contrôler la version de les changements vous rendre à une base de données tout au long du cycle de vie d'un projet, plutôt que de la base de données elle-même.
Cela vous permet d'appliquer de manière sélective des changements individuels à des environnements différents, tenir un journal des modifications de laquelle les modifications sont dans quel environnement, de créer des scripts pour appliquer les modifications de A à N, annulation des modifications, etc.
Ce n'est pas le moteur de base de données dépendantes. Par Microsoft SQL Serveur il y a beaucoup de version de contrôle des programmes. Je ne pense pas que le problème peut être résolu avec git, vous devez utiliser un pgsql schéma spécifique système de contrôle de version. Je ne sais pas si une telle chose existe ou pas...
Voici ce que j'essaie de faire dans mes projets:
La base de données de configuration sont stockées dans le fichier de configuration qui n'est pas sous contrôle de version (.gitignore)
La base de données par défaut (pour la mise en place de nouveaux Projets) est un simple fichier SQL sous contrôle de version.
Pour le schéma de base de données créer un schéma de base de données de vidage sous le contrôle de version.
La façon la plus commune est d'avoir des scripts de mise à jour qui contient des Instructions SQL (ALTER Table.. ou mise à JOUR). Vous devez aussi avoir une place dans votre base de données où vous enregistrez la version actuelle de vous du schéma)
Jetez un oeil à d'autres grands open source de base de données de projets (piwik,ou votre favori système cms), ils utilisent tous updatescripts (1.sql,2.sql,3.sh,4.php.5.sql)
Mais c'est un très consommateur de temps de travail, vous devez créer et tester la updatescripts et vous devez exécuter une commune updatescript qui compare la version et l'exécution de tout le nécessaire de mise à jour des scripts.
Donc, en théorie (et c'est ce que je suis à la recherche d'), vous pourriez
sous-évaluées de la du schéma de base de données après chaque modification (manuellement, conjob, git crochets (peut-être avant de s'engager))
(et seulement dans certains cas très particuliers de créer updatescripts)
Après que, dans votre commune updatescript (exécuter la normale updatescripts, pour les cas particuliers), puis de comparer les schémas (le vidage et la base de données en cours) et de générer automatiquement les nessesary Instructions ALTER. Il y a quelques outils qui peuvent le faire déjà, mais n'ont pas encore trouvé un bon.