@RomanGorbatko
PHP, Python, NodeJS, Swift

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

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

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


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

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

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

Фух... Выговорился.
  • Вопрос задан
  • 3202 просмотра
Пригласить эксперта
Ответы на вопрос 5
papahoolio
@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
Ответ написан
Fesor
@Fesor
Full-stack developer (Symfony, Angular)
вам нужно синхронизировать структуру базы между разработчиками? Миграции... и все... храните их в git, если кто-то поменял структуру базы - пишется миграция (а еще лучше менять базу только миграциями) и пушится, остальные разработчики забирают себе изменения и после каждого пула/мерджа делают migration up. Можно даже на пост-хуки повесить.

Синхронизация же данных между разработчиками ненужна. Если и должны быть какие-от обязательные данные - их можно опять же в миграцию запихнуть.
Ответ написан
Мы используем git репо с миграционниками в виде sql и скрипт phing для развёртывания/отката структуры базы, при чём можно как пошагово накатывать до актуального состояния, так и откатывать. То есть каждый миграционник имеет 2 блока: для наката и для отката.
Чтобы хранить информацию о текущем состоянии есть табличка в базе.
Ответ написан
7workers
@7workers
я вот так делал когда-то своим велосипедом: habrahabr.ru/post/80486/ Суть почти как у вас, но вместо одно файла каждый раз создаётся новый. И каждый mysql сервер "помнит" какой последйни патч он выполнил.

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

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы