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

Проблема заключается в синхронизации между рабочими машинами 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 и забирают от-туда себе запросы, тем самым обновляя самих себя.

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


_____________
Гнусный социопат с комплексом Бога.

решением называется версионность бд и миграции

изменения не пишутся в один файл, они пишутся в скрипты,
каждый новый патч, новый скрипт, притом который подразумевает откат

после на проекте постоянно с апом запускается миграция, и патчи автоматом применяются, исходя из текущей версии

Есть пример готовых решений или где можно об этом почитать?

P.S.: возможно я не умею эффективно пользоваться гуглом, но поиск навскидку ничего годного не показал.

_____________
Гнусный социопат с комплексом Бога.

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

Боюсь что выдернуть его отдельно не получится.слишком сильно вшит в движок.

RCuPeR

Я как-то, давненько уже правда, работал в конторе где тоже работало с десяток программеров над одним большим проектом. ТОгда мы еще работали через subversion и прекрасно обходились одним файлом, куда каждый добавлял необходимые SQL инструкции. Правда никакого лога кто их уже у себя применил мы не вели, поскольку никакой необходимости лично я в этом не вижу. Такой подход всегда казался мне довольно нормальным.

_____________
Senior PHP developer: PHP5, MySQL, JavaScript, CakePHP, Yii/Yii2, Zend Framework, Smarty, XML/Xslt, JQuery, Jquery Mobile, Bootstrap, ExtJS, HTML, HTML5, CSS, Linux, SVN, Git, Memcached, Redis, MongoDB, Zend Guard, Ioncube, FFMpeg, PayPal, Webmoney, Qiwi, Facebook API, Vkontakte Api, Google API, Twitter Api, Steam Api.
Junior Android Developer: Android SDK, многопоточность, работа с HTTP запросами, JSON, SQLite, фрагменты.

vagrand, очень не удобно. 2013 год скоро сменится 2014-ым, а работаем в этой области примитивно.

RCuPeR

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



_____________
Гнусный социопат с комплексом Бога.

Храните время апа в файле который в гитигноре. Все запросы по изменениям храните с меткой времени.подгрузку новых можно скриптом организовать. Такой подход тоже юзал было дело

апну тему.

пишу свой класс работы с БД (http://phpforum.ru/index.php?showtopic=77614&st=255&hl=). На момент написания топика, он умел строить пхп-схему на основе sql, сейчас он уже умеет производить обратную операцию - рисовать sql создания табличек по схеме, и вот буквально только что научил его рисовать sql с ALTER-ами.

работает примерно так:

$exporter = new Exporter();
$exporter->readSchema($schema);
$exporter->compareWithSQLFile('your_db_schema.sql');
$exporter->save('alter.sql');

в боевых условиях еще не проверял, сферический юнит-тест в вакууме проходит. Пока что поддерживает не очень много типов данных: integer, varchar(с указанием лимита), float, bool, text, timestamp, date, понимает not null, понимает первич.ключи и auto_increment (mysql) / serial (postgresql), понимает внешние ключи, но внешние ключи только простые (из одной колонки) и ссылающиеся только на первич.ключ.

в результате сгенерит чото типа того:

-- ALTER TABLE apdo_test_fruit DROP treeeee_id;

-- DROP TABLE apdo_test_drop;

-- ALTER TABLE apdo_test_tree MODIFY name varchar(20);

CREATE TABLE apdo_test_tree_extra (
    id integer NOT NULL AUTO_INCREMENT,
    height integer,
    tree_id integer NOT NULL,

    FOREIGN KEY (tree_id) REFERENCES apdo_test_tree(id),
    UNIQUE KEY (tree_id),
    PRIMARY KEY (id)
);

ALTER TABLE apdo_test_fruit ADD tree_id integer;

ALTER TABLE apdo_test_fruit ADD FOREIGN KEY (tree_id) REFERENCES apdo_test_tree(id);

код лежит на гитхабе в ветке alpha https://github.com/Aequiternus/APDO/tree/alpha