Utilisation de Git pour suivre le schéma mysql - quelques questions

si cela est recommandé ?

puis-je demander des exemples de commandes git sur la façon de suivre les versions du schéma mysql?

devrions-nous utiliser un autre dépôt que celui que nous utilisons normalement sur notre application root ?

devrais-je utiliser quelque chose appelé crochet ?

mise à Jour:

1) nous naviguons sur notre projet root où .git base de données réside.

2) nous créons un sous dossier appelé crochets.

3) nous avons mis quelque chose comme ça dans un fichier appelé db-commit:

   #!/bin/sh
   mysqldump -u DBUSER -pDBPASSWORD  DATABASE --no-data=true> SQLVersionControl/vc.sql
   git add SQLVersionControl/vc.sql
   exit 0

nous pouvons Maintenant:

4)git commit -m

cette propagation inclut un dump de schéma mysql qui a été lancé juste avant la propagation.

La source de ce qui précède est ici: http://edmondscommerce.github.io/git/using-git-to-track-db-schema-changes-with-git-hook.html

Si c'est une façon acceptable de le faire, puis-je s'il vous plaît demander à quelqu'un avec patience de commenter ligne par ligne et avec autant de détails que possible, ce qui se passe ici:

#!/bin/sh
mysqldump -u DBUSER -pDBPASSWORD  DATABASE --no-data=true> SQLVersionControl/vc.sql
git add SQLVersionControl/vc.sql
exit 0

Merci beaucoup.

24
demandé sur Andy 2011-04-02 00:14:01
la source

8 ответов

en supposant que vous avez déjà un git repo, faites ce qui suit dans un script shell ou autre:

#!/bin/bash -e
# -e means exit if any command fails
DBHOST=dbhost.yourdomain.com
DBUSER=dbuser
DBPASS=dbpass # do this in a more secure fashion
DBNAME=dbname
GITREPO=/path/to/git/repo
cd $GITREPO
mysqldump -h $DBHOST -u $DBUSER -p$DBPASS -d $DBNAME > $GITREPO/schema.sql # the -d flag means "no data"
git add schema.sql
git commit -m "$DBNAME schema version $(`date`)"
git push # assuming you have a remote to push to

alors démarrez ce script sur une base quotidienne à partir d'un travail cron ou ce que vous avez.

EDIT: en plaçant un script dans $ gitdir/hooks/prévalidation (le nom est important), le script sera exécuté avant chaque livraison. De cette façon, l'état du schéma de la base de données est capturé pour chaque propagation, ce qui est logique. Si vous exécutez automatiquement ce script sql à chaque fois que vous commettre, vous allez exploser votre base de données, qui n'est pas logique.

#!/bin/sh

Cette ligne spécifie que c'est un script shell.

mysqldump -u DBUSER -pDBPASSWORD  DATABASE --no-data=true> SQLVersionControl/vc.sql

c'est la même chose que dans ma réponse ci-dessus; prendre le DDL seulement à partir de la base de données et le stocker dans un fichier.

git add SQLVersionControl/vc.sql

ajoute le fichier SQL à chaque propagation faite dans votre dépôt.

exit 0

ceci sort du script avec succès. C'est peut-être dangereux. Si mysqldump ou git add échec, vous pouvez souffle quelque chose que tu voulais garder.

23
répondu mkb 2011-04-02 02:20:23
la source

si vous suivez juste le schéma, mettez toutes les instructions CREATE en une seule .fichier sql, et ajouter le fichier à git.

$> mkdir myschema && cd myschema
$> git init
$> echo "CREATE TABLE ..." > schema.sql
$> git add schema.sql
$> git commit -m "Initial import"
9
répondu Chris Eberle 2011-04-02 00:25:30
la source

IMO la meilleure approche est décrite ici:http://viget.com/extend/backup-your-database-in-git

ce qui suit inclut un crochet de pré-propagation git pour capturer la base de données mysql/le schéma, donné à l'utilisateur='myuser', mot de passe='mypassword', database_name='dbase1'. Les erreurs de bulles correctement jusqu'au système git (le exit 0's dans d'autres réponses pourrait être dangereux et pourrait ne pas gérer correctement les scénarios d'erreur). Optionnellement, peut ajouter une importation de base de données à un crochet post-checkout (lors de la capture de toutes les données, pas seulement le schéma), mais prendre soin compte tenu de la taille de votre base de données. Détails dans les commentaires de bash-script dessous.

pre-commit hook:

#!/bin/bash

# exit upon error
set -e
# another way to set "exit upon error", for readability
set -o errexit

mysqldump -umyuser -pmypassword dbase1 --no-data=true > dbase1.sql

# Uncomment following line to dump all data with schema,
# useful when used in tandem for the post-checkout hook below.
# WARNING: can greatly expand your git repo when employing for
# large databases, so carefully evaluate before employing this method.
# mysqldump -umyuser -pmypassword dbase1 > dbase1.sql

git add dbase1.sql

(optionnel) après-caisse crochet:

#!/bin/bash
# mysqldump (above) is presumably run without '--no-data=true' parameter.
set -e
mysql -umyuser -pmypassword dbase1 < dbase1.sql

Versions des applications, OS Je cours:

[email protected] Dec 12 22:35:14 /var/www# mysql --version
mysql  Ver 14.14 Distrib 5.1.54, for debian-linux-gnu (x86_64) using readline 6.2
[email protected] Dec 12 22:35:19 /var/www# git --version
git version 1.7.4.1
[email protected] Dec 12 22:35:22 /var/www# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 11.04
Release:        11.04
Codename:       natty
[email protected] Dec 12 22:35:28 /var/www#
1
répondu Johnny Utahh 2011-12-13 17:52:01
la source

aussi brillant que cela paraisse (l'idée m'est venue aussi), quand j'ai essayé de l'implémenter, j'ai heurté un mur. En théorie, en utilisant le drapeau -- skip-extended-insert, malgré un largage initial important, les diffs entre les dumps quotidiens devraient être minimes, donc l'augmentation de taille au fil du temps du dépôt pourrait être considérée comme minime aussi, n'est-ce pas? Faux!

git stocke les shapshots, pas les diffs, ce qui veut dire qu'à chaque propagation, il prend tout le fichier dump, pas seulement la diff. De plus, puisque le dump avec --skip-extended-instert utilisera tous les noms de champ sur chaque ligne d'insertion, il sera énorme comparé à un dump fait sans --skip-extended-instert. Il en résulte une explosion de taille, exactement à l'opposé de ce que l'on attendrait.

dans mon cas, avec une décharge de ~ 300 Mo sql, le dépôt est passé à des gigaoctets en quelques jours. Alors, qu'ai-je fait? J'ai d'abord essayé la même chose, seulement enlever -- skip-extended-instert, de sorte que les décharges seront plus petites, et les instantanés seraient proportionnellement plus petites. Cette approche a duré un certain temps, mais avec le temps elle est devenue inutilisable aussi.

pourtant, l'usage diff avec -- skip-extended-insert semble toujours être une bonne idée, seulement, maintenant j'essaie d'utiliser subversion au lieu de git. Je sais, comparé à git, svn est une histoire ancienne, mais il semble fonctionner mieux, car il utilise en fait des diffs au lieu de snapshots.

donc en bref, je crois que la meilleure solution est de faire ce qui précède, mais avec subversion au lieu de Git.

1
répondu Tuncay Göncüoğlu 2012-05-03 17:24:30
la source

bien que je n'utilise pas Git, j'utilise le contrôle à la source depuis plus de 15 ans. Une pratique exemplaire à respecter lorsque vous décidez où et comment stocker votre src et les ressources qui l'accompagnent dans le contrôle Source: si le schéma de la base de données est utilisé dans le cadre du projet, alors vous devriez versionner le schéma et toutes les autres ressources du projet dans "ce" projet. Si vous développez un ensemble de schémas ou de ressources de programmation que vous réutilisez dans d'autres projets, alors vous devriez avoir un dépôt séparé pour ceux réutilisables. ressources. Ce projet distinct de ressources réutilisables sera versionné de lui-même et suivra les versions des ressources réutilisables réelles dans ce dépôt.

si vous utilisez une ressource suivie en versions à partir du dépôt réutilisable dans un autre projet, alors vous avez le scénario suivant, (juste un exemple). Projet XYZ version 1.0 utilise maintenant la version 4.0 DE DB Schema_ABC dans ce cas, vous comprendrez que vous avez utilisé une version spécifique d'une ressource réutilisable et puisqu'il est de version vous serez en mesure de suivre son utilisation tout au long de votre projet. Si vous recevez un rapport de bogue sur Dbshema_abc, vous pourrez corriger le schéma et la version de révision ainsi que comprendre où D'autre Dbshem_abc est utilisé et où vous pourriez avoir à faire quelques modifications. De là, vous comprendrez également quels projets contiennent des versions de quelles ressources réutilisables... Vous devez juste comprendre comment suivre vos ressources.

adoption de ce type d'environnement et de ressources de développement La stratégie de gestion est essentielle pour libérer des logiciels utilisables et gérer un environnement d'amélioration break/fix. Même si vous vous développez pour votre propre edificcation sur votre propre temps, vous devriez utiliser le contrôle de source.. comme vous êtes..

en ce qui concerne Git, je trouverais une interface graphique ou une intégration dev env si je le pouvais. Git est assez grand donc je suis sûr qu'il a beaucoup de soutien frontal, peut-être?

0
répondu apesa 2011-04-02 00:37:55
la source

(shameless plug)

outil de ligne de commande dbvc vous permet de gérer les mises à jour de votre schéma de base de données dans votre dépôt.

Il crée et utilise un tableau _dbvc dans la base de données qui contient une liste des mises à jour sont exécutées. Vous pouvez facilement exécuter les mises à jour qui n'ont pas encore été appliquées à votre schéma de base de données.

l'outil utilise git pour déterminer le bon ordre d'exécution mettre.

usage DBVC

Afficher une liste de commandes

dbvc help

Afficher l'aide sur une commande

dbvc help init

initialiser DBVC pour une base de données existante.

dbvc init

créer un dump de base de données. Ceci est utilisé pour créer le DB sur un nouvel environnement.

mysqldump foobar > dev/schema.php

créer la base de données en utilisant le schéma.

dbvc create

Ajouter un fichier de mise à jour. Ceux-ci sont utilisés pour mettre à jour le DB sur d'autres environnement.

echo 'ALTER TABLE `foo` ADD COLUMN `status` BOOL DEFAULT 1;' > dev/updates/add-status-to-foo.sql

Marquer une mise à jour comme déjà exécuté.

dbvc mark add-status-to-foo

Afficher une liste des mises à jour qui doivent être exécutées.

dbvc status

Afficher toutes les mises à jour avec leur statut.

dbvc status --all

mettre à jour la base de données.

dbvc update
0
répondu Jasny - Arnold Daniels 2014-08-02 07:41:36
la source

j'ai trouvé que les options suivantes sont obligatoires pour un contrôle de version / mysqldump compatible git.

mysqldump --skip-opt --skip-comments |sed -e 's/DEFINER[ ]*=[ ]*[^*]*\*/\*/'

(et peut-être --no-data)

--skip-opt est très utile, il enlève tout --add-drop-table --add-locks --create-options --disable-keys --extended-insert --lock-tables --quick --set-charset. DEFINER sed est nécessaire lorsque la base de données contient des déclencheurs.

0
répondu Blauhirn 2018-01-14 17:44:30
la source

Autres questions sur