Синхронизация MySQL запросов

Question

[Roman Gor]

Всем привет!
Хочу поделится проблемой которая существует в нашей компании, и узнать возможные пути ее решения.

Проблема заключается в синхронизации между рабочими машинами MySQL запросов.
Объясню подробней.
В нашем офисе работает N (пример 5) программистов, примерно, такое же количество программистов работает на удаленке + штатные разработчики могут работать дома. Посчитаем примерное количество локальных виртуальных серверов: 5 (на офисе) + 5 (удаленка) + 5 (офисные работники работают дома) = 15 машин.
Вся наша работа сваливается (через GIT) на какой-то pre-production сервер, назовем его site.alpha. Как синхронизировать версионность исходников проекта мы разобрались, уже около года успешно работаем с GIT. А вот как синхронизировать MySQL-запросы - не понятно.
Сейчас все это дело происходит по следующей схеме. Если мне нужно внести какие-то изменения в структуру БД, я выполняю запрос у себя на локальной машине и копирую его в некий файл Patch.sql, который потом сливаю в GIT. Далее, мои коллеги, если замечают какие-то изменения в файл-патче БД, они выполняют запрос у себя на машине и дописывают в файл-патч что-то типа:

-- 06.02.13 11:05 Roman Ivanov [e-mail] Work
-- 06.02.13 11:05 Boris Petrov [e-mail] Home
....

Т.е., в комментариях к запросу мы ведем некий лог их (запросов) выполнения каждым разработчиком. Жесть, да?! Проблема усложняется еще и тем, что старшему разработчику нужно постоянно следить за этими логами, и после выполнения запроса всеми разработчиками - выполнить этот же запрос на site.alpha.
Сейчас у нас этот Patch.sql уже занимает несколько сотен МБ.

Вот хотел спросить: как вы решаете проблему в своей компании?

P.S. Про репликацию, конечно, слышал, но мне кажется, это немного не то, что нам нужно. А нужно следующее. Какой-то master-slave скрипт, который будет следить за состоянием локальной базы (slave) и центральной (master). В случае если на slave БД что-то изменилось, он составляет запрос которым нужно проапдейтить master и остальные slave и отправляет его по всем остальным серверам, или сгружает все на master, а slave-ы других локальных серверов мониторят непосредственно master и забирают от-туда себе запросы, тем самым обновляя самих себя.

Фух... Выговорился.

Answer 1

[papahoolio]

Миграции.

Идея миграций - вынести создание и изменение структуры бд в программный код. Одно изменение - одна миграция. Миграции имеют порядковый номер и соответственно выполняются друг за другом согласно порядковому номеру, где-то в системе всегда хранится номер миграции, которая была применена последней.

Главное в миграциях, что после того, как она попала в репозитарий проекта, она изменяться уже не должна! Если нужно отменить изменения уже опубликованной миграции, пишется новая, отменяющая/исправляющая старую.

Разработчики должны изменения структуры/наполнение бд делать только миграциями.

Опять же для CodeReview миграции просто отличный инструмент.

Для PHP
Например в Yii:
www.yiiframework.com/doc/guide/1.1/ru/database.mig...

Как отдельно решение
https://github.com/ruckus/ruckusing-migrations

Для Python:
https://pypi.python.org/pypi/alembic

bash:
https://github.com/dwb/dogfish/blob/master/dogfish

Comments

[Roman Gor]

"вынести создание и изменение структуры бд в программный код" - имеется ввиду только структура или можно еще мигрировать данные? В моей случае, именно данные являются основной проблемой.

[papahoolio]

И данные тоже можно.

По факту у тебя просто будет набор команд на выбранном для проекта языке программирования, которые делают с базой что-то: создают таблицы, удаляют таблицы, изменяют поля в таблице, добавляют данные в таблицы.

[papahoolio]

Главное в миграциях, что после того, как она попала в репозитарий проекта, она изменяться уже не должна! Если нужно отменить изменения уже опубликованной миграции, пишется новая, отменяющая/исправляющая старую.

Разработчики должны изменения структуры/наполнение бд делать только миграциями.

Опять же для CodeReview миграции просто отличный инструмент.

[Roman Gor]

А как обстоит дело с автоматизацией? Какой вообще принцип работы миграции? Получается, я на своей машине создал некую миграцию, и отправил ее на сервер (гитом), на сервере стоит какой-то демон, который применяет миграцию к своей базе и т.д.?

[int03e]

Обычно миграция пушится в репу, дальше каждый разработчик делает git pull, и применяет эту миграцию на своей локальной БД. В случае деплоя на продакш/стейджинг/тестовый сервер миграции накатываются автоматически ( к примеру с помощью capistrano). Все удобно и прозрачно.

Answer 2

[Сергей Протько]

вам нужно синхронизировать структуру базы между разработчиками? Миграции... и все... храните их в git, если кто-то поменял структуру базы - пишется миграция (а еще лучше менять базу только миграциями) и пушится, остальные разработчики забирают себе изменения и после каждого пула/мерджа делают migration up. Можно даже на пост-хуки повесить.

Синхронизация же данных между разработчиками ненужна. Если и должны быть какие-от обязательные данные - их можно опять же в миграцию запихнуть.

Comments

[Roman Gor]

Есть какие-то готовые решения? Или где-то подробней почитать об этом?

[Сергей Протько]

я использую doctrine-migrations

[Roman Gor]

Но у вас, видимо, и проект с использованием doctrine?

[Сергей Протько]

да, но doctrine-migrations можно спокойно использовать отдельно, оно просто будет использовать doctrine dbal для себя. Саму orm для этого ставить ненужно.

Answer 3

[Александр]

Мы используем git репо с миграционниками в виде sql и скрипт phing для развёртывания/отката структуры базы, при чём можно как пошагово накатывать до актуального состояния, так и откатывать. То есть каждый миграционник имеет 2 блока: для наката и для отката.
Чтобы хранить информацию о текущем состоянии есть табличка в базе.

Comments

[Алексей Журбицкий]

Используете dbdeploy или какое-то другое решение?

[Александр]

@blo dbdeploy

Answer 4

[Max]

я вот так делал когда-то своим велосипедом: habrahabr.ru/post/80486/ Суть почти как у вас, но вместо одно файла каждый раз создаётся новый. И каждый mysql сервер "помнит" какой последйни патч он выполнил.

Но есть и готовые решения (почитайте коменты).

Answer 5

[evnuh]

Если не хочется возиться с миграциями в коде, как вам уже предложили, то простейшим (колхозным) вариантом является выноска очередных команд на изменение БД в отдельный файл, который кладется в папку со всеми такими-же файлами. Папка, соответственно, под гитом. И вешаем пост-хук в гите на выполнение команды (bash скрипта?), который бы применил новый файл всем в бд, кому пришел этот файл.

Comments

[Roman Gor]

Но этот "пост-хук" не может же следить за версиями файлов. Т.е., если я в свой файл запишу запрос на вставку нового юзера (например), он будет выполнятся при каждом пуле, так?