Хабрахабр

[Из песочницы] Механизм контроля версий базы данных в GIT (управление дампами MySQL)

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

Что это?

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

Для кого?

Либо у вас мало денег (или жаба душит) чтобы тратить их на хорошие продукты контроля версий БД. К примеру вы предпочитаете разрабатывать сайт сразу на хостинге заказчика и контролировать ход разработки и изменения в БД. И конечно пригодится если вы начинающий разработчик и только начинаете осваивать азы разработки, и у вас периодически происходит 500-я и вы не знаете почему. Вы также можете использовать проект в качестве бекапера данных по определенным правилам, который можно использовать по крону. Либо вы разрабатываете продукт командой и хотите автоматически при пуше в мастер синхронизировать его с продакшеном для оценки заказчика.

Рассмотрим пример стандартной разработки сайта на стороне хостера (большинство случаев):

  1. Есть сервер, на котором крутится проект и скорее всего это либо локальная машина, либо хостинг клиента текущего проекта.
  2. Есть локальный компьютер, за которым вы работаете и по традиции там же храните файлики и снимки состояний.
  3. И Продакшен, это то куда сливается итоговый продукт — но он может являтся и 1-м пунктом просто другой папкой.

Как с этим работать?

Для этого я использовал хуки гита, которые представляют из себя файлики соответствующих скриптов (они должны быть установлены на локальном компьютере, где используется git). Для того, чтобы соблюсти контроль версии базы данных используя гит, очевидно нужно получать ее дампы на некоторых этапах, где то их хранить, и при переключении веток учитывать этот момент. В зависимости от настроек конфигурационного файла процесс работы может выглядеть следующим образом:

Т.е. Создаем ветку (автоматически произошел бекап) и переключаемся, работаем, добавляем файлики, создаем комит (автоматически произошел бекап)…
переключились на мастер верку, произшло переключения БД на предыдущее состояние…
вернулись в разработку, слили ветки, запушили. Вы можете вручную вызывать экспорт либо импорт БД на сервере, с вашего локального компа, запуская соответствующий скрипт. бекапы автоматом создаются при комитах,
либо принудительно перед чекаутом, поведение настраивается в конфиге.

У каждого скрипта можно получить справку классическим путем через аргумент -h либо --help.

Поэтому вы можете легко настроить используя config.ini Так как настройки используются и на серверной стороне (на которой поднят mySql) и клиентской (комп разработчика), то за настройку отвечает один и тот же файл. Я не рекомендую бекапить всю БД, гит не любит больших файлов, да и в большинстве случаев это и не нужно. И Конечно это может быть один и тот же компьютер, если вы ведете разработку локально.

Что можно настраивать для создания дампа

  • Настройки подключения к БД и пути храния дампов
  • Указание провайдера, который сможет не только получить данные подключения к БД, но
    и правильно очистить кеш на сервере при переключении веток.
  • Экспорт всей БД
  • Список таблиц которые нужно исключить из экспорта
  • Либо экспорт определенных таблиц
  • Сохранение структуры без вставки данных у определенных таблиц
  • Указание полей у таблиц значения которых не должны экспортироваться, и должны
    быть заменены значениями по умолчанию.
  • Отдельные наборы правил в одном конфиге, что позволит делать различные бекапы по CRON-у

Я использовал файлы — провайдеры. Для того чтобы облегчить процесс создания дампов. На его основе можно написать такой же провайдер для любой CMS. И настроил (пока один единственный) для CMS MODX revolution.

Краткие шаги к началу работы

Скачаем проект, рекомендую положить в папку рядом с .git, либо внутрь проекта, скрипт все равно найдет git [git clone ](https://github.com/Setest/.git-db-watcher) установим права на запуск на локальном компе и сервере
chmod +x install.sh; ставим локально
./install.sh ставим на сервере, где не нужны хуки ./install.sh -nh

Для примера вот так: Теперь необходимо внести правки в config.ini.

;общий раздел
[hooks] ; H_CHECK_DB_HASH_BEFORE_CHECKOUT=1 ; импорт файла БД даже если checkout происходит на эту же ветку ; также это правило распростроняется при переключении на вновь созданную ветку ; через git checkout -b new_branch_name H_CHECKOUT_FORCE=0 ; автоматическое добавление файла БД при каждом комите H_CHECKOUT_EVERCOM=1 ;автоматическая очистка директории кеша после переключения БД H_CHECKOUT_CLEARCACHE=1 [common] ;результирующий файл в который будут экспортироваться данные EXPORT_FILE="db.sql"
;на локальном компе используется из хуков гита и ручного экспорта БД
;через запуск файла ./export.sh [develop] ;скрипт запуска db_export.sh на сервере CLI_DB_EXPORT="ssh host '/path/to/project/on/server/.git-db-watcher/db_export.sh'" CLI_DB_IMPORT="ssh host '/path/to/project/on/server/.git-db-watcher/db_import.sh'" ;только на сервере
[server] PHP_PATH="/usr/local/bin/php" CONFIG_INC_PATH="/path/to/project/on/server/core/config/config.inc.php" PROVIDER=modx DB_TABLES_INCLUDE=site_content DB_TABLES_AUTOPREFIX=1 [server_full_site] PHP_PATH="/usr/local/bin/php" CONFIG_INC_PATH="/path/to/project/on/server/core/config/config.inc.php" ; '' - берет данные из настроек с префиксом DB_CONFIG_ иначе из файла лежащего ; папке providers PROVIDER=modx ;не обязательно но можно указать настройки вручную если нет провайдера DB_CONFIG_HOST= DB_CONFIG_TYPE= DB_CONFIG_USER= DB_CONFIG_PASSWORD= DB_CONFIG_CONNECTION_CHARSET= DB_CONFIG_DBASE= DB_CONFIG_TABLE_PREFIX= DB_CONFIG_DATABASE_DSN= ;если указаны то будут экспортированы только эти таблицы (разделитель пробел) ;заворачивать строку в кавычки нельзя ; DB_TABLES_INCLUDE=manager_log register_messages user_attributes ; DB_TABLES_INCLUDE=site_content ;таблицы исключаемые из экспорта ; DB_TABLES_EXCLUDE=session register_messages mse2_words ec_messages ;добавление префиксов, взятых из файла конфигурации, к именам таблиц DB_TABLES_AUTOPREFIX=1 ;таблицы из которых будет удалены запросы на INSERT DB_TABLES_REMOVE_INSERT="manager_log session register_messages" ; DB_TABLES_REMOVE_INSERT="manager_log" ;список таблиц поля которых будут выставлены по умолчанию ; DB_TABLES_DEFAULT=user_attributes users DB_TABLES_DEFAULT=user_attributes ;список полей соответствующих таблице, значения кот будут выставлены ;по умолчанию в соответствие с со структурой таблицы, это не обязательно и ; можно не указывать DB_TABLES_DEFAULT_user_attributes=sessionid logincount lastlogin thislogin ; DB_TABLES_DEFAULT_users=session_stale ;получает только пользователей, с удалением лишних данных
[only_users] DB_TABLES_INCLUDE=user user_attributes EXPORT_FILE="users.sql" DB_TABLES_DEFAULT=user_attributes user DB_TABLES_DEFAULT_user_attributes=sessionid logincount lastlogin thislogin DB_TABLES_DEFAULT_users=session_stale

Если все настроено правильно можно запустить ./export.sh и у вас должен
появиться дамп БД на локальном компе и на сервере.

Остальные вопросы

Мне нужно сохранить результат на сервере в другое место:

./db_export.sh --output 1>./xxx.sql

Хочу производить экспорт на сервере используя данные своего раздела файла конфигурации:

./db_export.sh -с=only_users --output 1>./users.sql

Хочу импортировать файл БД, но не хочу это делать через перехватчики GIT-а?

./import.sh ./import.sh EXPORT_FILE=site_name.sql ./import.sh DB_BACKUP_FILE=/.../../site_name.sql ./import.sh --config=site DB_BACKUP_FILE=./site_name.sql

A как производить импорт находясь на сервере?

./db_import.sh < db_backup/db.sql

В разных проектах я использую CMS xxx и мне надоело каждый раз вводить данные
для управления БД, как можно упростить процесс?

Для этого нужно написать свой файл провайдера по аналогии с имеющимися.

Я создал задание CRON и конфигурацию с использованием провайдера php, но оно
не выполняется, либо кеш сайта CMS не очищается, в чем может быть дело?

В зависимости от настроек сервера и самого задания, задания CRON могут запускаться совсем в другом окружении, в котором путь к php препроцессору может отличаться и как следствие, запускать совсем другую версию php не совместимую с той, на которой работает ваша CMS.

Послесловие

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

И не стоит сразу вонять, что ничего не работает, возможно вы не смогли разобраться в том как произвести правильную настройку и установку (в особенности если вы работаете на Windows, все же BASH это линуксовая среда).

Я старался сразу писать на английском, но и из-за моего любительского уровня, возможно будет не все понятно, в дальнейшем напишу на русском. Инструкция по установке и использованию лежит в README. A если есть хорошие советы — поделитесь. Если есть желание внести правки в перевод или код, форкайте на здоровье!

S: если вы дочитали до саааааамого низа, значит Вам стало интересно и не терпится попробовать 🙂 P.

Тогда тычь смелее на эту ссылочку!

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть