Использование Git для отслеживания схемы mysql - некоторые вопросы

Ответ 1

Предположим, что у вас уже есть репозиторий git, выполните следующие действия в оболочке script или что-то еще:

#!/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

Затем запустите этот script каждый день из задания cron или того, что у вас есть.

EDIT: поместив script в $gitdir/hooks/pre-commit (имя важно), script будет выполняться перед каждым фиксацией. Таким образом, состояние схемы БД фиксируется для каждой фиксации, что имеет смысл. Если вы автоматически запускаете этот sql script каждый раз, когда вы совершаете фиксацию, вы удаляете свою базу данных, что не имеет смысла.

#!/bin/sh

Эта строка указывает, что это оболочка script.

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

Это то же самое, что и в моем ответе выше; беря DDL только из базы данных и сохраняя ее в файле.

git add SQLVersionControl/vc.sql

Это добавляет файл SQL к каждой фиксации, сделанной в ваш репозиторий.

exit 0

Это успешно завершает работу script. Это возможно опасно. Если mysqldump или git add терпят неудачу, вы можете сдуть то, что хотите сохранить.

Ответ 2

Если вы просто отслеживаете схему, поместите все инструкции CREATE в один .sql файл и добавьте файл в git.

$> mkdir myschema && cd myschema
$> git init
$> echo "CREATE TABLE ..." > schema.sql
$> git add schema.sql
$> git commit -m "Initial import"

Ответ 3

ИМО здесь описывается лучший подход: http://viget.com/extend/backup-your-database-in-git. Для вашего удобства я повторяю наиболее важные части здесь.

Трюк заключается в использовании mysqldump --skip-extended-insert, который создает дампы, которые можно лучше отслеживать/различать по git.

Есть также некоторые подсказки относительно лучшей конфигурации репозитория, чтобы уменьшить размер диска. Скопировано из здесь:

• core.compression = 9: флаг для gzip для определения уровня сжатия для блоков и пакетов. Уровень 1 быстрый с большими размерами файлов, уровень 9 занимает больше времени, но приводит к лучшему сжатию.
• repack.usedeltabaseoffset = true: по умолчанию значения false для совместимости, но поддерживается с помощью Git >= 1.4.4.
• pack.windowMemory = 100 м: (Re) упаковочные объекты могут потреблять много памяти. Чтобы предотвратить утечку всех ресурсов, полезно ограничить это. Существует также pack.deltaCacheSize.
• pack.window = 15: по умолчанию 10. При более высоком значении Git пытается найти похожие капли.
• gc.auto = 1000: по умолчанию - 6700. Как указано в статье, рекомендуется запускать Git gc каждый раз в то время. Лично я запускаю Git gc --auto каждый день, так что только упаковывайте вещи, когда там хватает мусора. Git gc -auto обычно запускает механизм упаковки только при наличии 6700 свободных предметов. Этот флаг снижает эту сумму.
• gc.autopacklimit = 10: по умолчанию 50. Каждый раз, когда вы запускаете Git gc, создается новый пакет из свободных объектов. Со временем вы получаете слишком много пакетов, которые теряют пространство. Это хорошая идея объединить все пакеты раз в то время в один пакет, поэтому все объекты могут быть объединены и дефинированы. По умолчанию Git gc делает это, когда вокруг 50 пакетов. Но для этой ситуации более низкое число может быть лучше.

Старые версии можно обрезать с помощью:

git rebase --onto master~8 master~7

(скопировано из здесь)

Ответ 4

Ниже приведена привязка git pre-commit для захвата базы данных/схемы mysql, заданной пользователем = 'myuser', password = 'mypassword', database_name = 'dbase1'. Правильно выдает ошибки до системы git (exit 0 в других ответах может быть опасным и может неправильно обрабатывать сценарии ошибок). Необязательно, можно добавить импорт базы данных в крюк после проверки (при захвате всех данных, а не только схемы), но будьте осторожны, учитывая размер вашей базы данных. Подробности в bash - script комментарии ниже.

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

(необязательно): после проверки:

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

Версии приложений, ОС, в которых я запущен:

[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#

Ответ 5

Как блестящий, как это звучит (идея мне тоже пришла в голову), когда я попытался ее реализовать, я ударил стену. Теоретически, используя флаг -skip-extended-insert, несмотря на то, что начальный дамп был бы большим, различия между ежедневными дампами должны быть минимальными, поэтому увеличение размера со временем репозитория можно считать минимальным, право? Неправильно!

Git хранит снимки, а не разности, что означает, что каждый фиксатор принимает весь файл дампа, а не только diff. Более того, поскольку свалка с -skip-extended-instert будет использовать все имена полей на каждой отдельной строке вставки, она будет огромной по сравнению с дампом, выполненной без --skip-extended-instert. Это приводит к взрыву в размере, прямо противоположному тому, что можно было бы ожидать.

В моем случае, с дампом sql ~ 300MB, хранилище перешло в гигабайты в днях. Итак, что я сделал? Сначала я попробовал то же самое, удаляю только -skip-extended-instert, так что дампы будут меньше, а снимки будут пропорционально меньше. Этот подход длился некоторое время, но со временем он стал непригодным.

Тем не менее, использование diff с -skip-extended-insert фактически все еще казалось хорошей идеей, только теперь я пытаюсь использовать subversion вместо git. Я знаю, по сравнению с git svn - это древняя история, но, похоже, она работает лучше, поскольку на самом деле она использует diff вместо снимков.

Итак, я считаю, что лучшее решение делает выше, но с subversion вместо git.

Ответ 6

Пока я не использую Git, я использовал контроль источника более 15 лет. Лучше всего придерживаться при определении того, где и как хранить свои ресурсы и ресурсы в Source Control: если в проекте используется схема базы данных, тогда вы должны управлять версиями схемы и всех других ресурсов проекта в этом "проекте". Если вы разрабатываете набор схем или ресурсов программирования, которые вы используете в других проектах, тогда у вас должен быть отдельный репозиторий для тех ресурсов, которые можно повторно использовать. Этот отдельный проект ресурсов многоразового использования будет версироваться по своему усмотрению и будет отслеживать версии реальных ресурсов многократного использования в этом репозитории.

Если вы используете ресурс с версией из многоразового репозитория в другом проекте, вы имеете следующий сценарий (просто пример). В Project XYZ версии 1.0 теперь используется DB Schema_ABC версии 4.0. В этом случае вы поймете, что используете конкретную версию ресурса многократного использования, и поскольку она версирована, вы сможете отслеживать ее использование во всем проекте. Если вы получите отчет об ошибке в DBSchema_ABC, вы сможете исправить схему и повторную версию, а также понять, где используется DBSchem_ABC, и где вам, возможно, придется внести некоторые изменения. Оттуда вы также поймете, какие проекты содержат версии, из которых можно использовать многоразовые ресурсы... Вам просто нужно понять, как отслеживать ваши ресурсы.

Принятие этого типа разработки. Стратегия управления средой и ресурсами - ключ к выпуску полезного программного обеспечения и управлению средой улучшения перерыва/исправления. Даже если вы разрабатываете свое собственное учение в свое время, вы должны использовать источник управления.. как вы..

Что касается Git, я мог бы найти интерфейс gui или интеграцию dev env, если смогу. Git довольно большой, поэтому я уверен, что у него много поддержки на лицевой панели, может быть?

Ответ 7

(бесстыдный плагин)

инструмент командной строки dbvc позволяет вам управлять обновлениями схемы базы данных в вашем репозитории.

Он создает и использует таблицу _dbvc в базе данных, которая содержит список запущенных обновлений. Вы можете легко запускать обновления, которые еще не применялись к вашей схеме базы данных.

Инструмент использует git для определения правильного порядка выполнения обновлений.

Использование DBVC

Показать список команд

dbvc help

Показать справку по определенной команде

dbvc help init

Инициализировать DBVC для существующей базы данных.

dbvc init

Создайте дамп базы данных. Это используется для создания БД в новой среде.

mysqldump foobar > dev/schema.php

Создайте БД с помощью схемы.

dbvc create

Добавить файл обновления. Они используются для обновления БД в других средах.

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

Отметьте обновление как уже выполненное.

dbvc mark add-status-to-foo

Показать список обновлений, которые необходимо запустить.

dbvc status

Показать все обновления с их статусом.

dbvc status --all

Обновить базу данных.

dbvc update