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

Question

Если это рекомендуется?

Могу ли я попросить несколько примеров команд git о том, как отслеживать версии схемы mysql?

Должны ли мы использовать другой репозиторий, отличный от того, который мы обычно используем в корне нашего приложения?

Должен ли я использовать то, что называется крючком?

Обновление:

1) Мы переходим в корень нашего проекта, где находится база данных .git.

2) Мы создаем подпапку с именем hooks.

3) Мы помещаем нечто подобное в файл с именем db-commit:

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

Теперь мы можем:

4) git commit -m

Этот коммит будет включать дамп схемы mysql, который был запущен непосредственно перед коммитом.

Источник выше здесь: http://edmondscommerce.github.io/git/using-git-to-track-db-schema-changes-with-git-hook.html

Если это приемлемый способ сделать это, могу ли я попросить кого-нибудь с терпением комментировать построчно и как можно более подробно, что здесь происходит:

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

Большое спасибо.

Answer 1

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

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

Затем ежедневно запускайте этот сценарий из задания cron или чего-то еще.

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

#!/bin/sh

В этой строке указывается, что это сценарий оболочки.

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

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

git add SQLVersionControl/vc.sql

Это добавляет файл SQL к каждому коммиту, сделанному в вашем хранилище.

exit 0

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

Answer 2

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

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

Answer 3

IMO, лучший подход описан здесь: 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 = 100m : (Пере) упаковка объектов может занимать много памяти.Чтобы все ваши ресурсы перестали работать, полезно ограничить это.Существует также pack.deltaCacheSize.
• pack.window = 15 : по умолчанию 10. При более высоком значении Git старается найти похожие BLOB-объекты.
• 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

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

Answer 4

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

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

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

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

Короче говоря, я считаю, что лучшее решение - это описанное выше, но с использованием subversion вместо git.

Answer 5

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

хук предварительной фиксации:

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

Версии приложений, ОС, на которых я работаю:

root@node1 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
root@node1 Dec 12 22:35:19 /var/www# git --version
git version 1.7.4.1
root@node1 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
root@node1 Dec 12 22:35:28 /var/www#

Answer 6

Я считаю следующие параметры обязательными для контроля версий / git-совместимого mysqldump.

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

(а может и --no-data)

--skip-opt очень полезно, отнимает все --add-drop-table --add-locks --create-options --disable-keys --extended-insert --lock-tables --quick --set-charset. DEFINER sed необходим, когда база данных содержит триггеры.

Answer 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

Answer 8

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

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

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

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