Синхронизация структуры MySQL

[Bal]

1. Никогда не меняю ничего в имеющейся структуре так, чтобы это могло привести к потере данных. Только расширения и модификации.

2. Вследствие этого спокойно меняю структуру на продакшне без боязни что-то ломать.

3. Потом mysqldump | mysql — и изменения с продакшна у меня на тестовом вместе со свежими данными.

4. Вношу нужные правки в код тестового и отлаживаю его.

5. Коммичу изменения кода тестового на продакшн.

[MAnt]

Всю базу дампить можно при маленьком ее размере… а если 10 гигов?

[Bal]

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

…

У меня на форуме база сообщений всего 3,5Гб, и то каждая модификация — это СОБЫТИЕ. Одно только перестроение индексов при ALTER TABLE идёт минут по 40.

[Bal]

s/форммажор/форсмажор/

[shuvalov]

Я всегда стараюсь держать структуру базы в репозитории — например, так — для каждой таблицы файлик с CREATE TABLE, тоже самое для хранимых процедур триггеров. Но вот автоматизировать, имхо это не стоит. Если при откате скрипт сделает ALTER TABLE DROP column — у меня могут потеряться данные в каком-то поле — может я временно отктатился, а потом вернусь назад, а даных то уже нет. Так что лучше уж сразу планировать БД так, что бы она не приводила к конфликтам. А поводу инкрементального развития(новые поля, таблицы) можно дописывать в репозиторий ALTER TABLE`ы(вы ведь их все равно у себя делаете) а потом выполнять их на продакшене.

[MAnt]

Да, так и делаю — руками после каждого switch'a. Для меня идеальный вариант — использовать svn hook для изменения структуры на production (быстро и помнить не надо), но пока осторожен с автоматизацией.

[Jama]

Еще не разу не откатывался после изменения структуры базы. Каждое такое изменение очень тщательно продумываем. Никто, конечно, не застрахован. С интересом буду следить за комментариями :-) Вдруг пригодится.

[7workers]

всегда синхронизирую вручную, да и делать это приходится всего несколько раз за проект. Если вам нужно делать это через день — у вас не production, а ещё один dev-сервер по-моему.

[MAnt]

12 программистов, соответственно темп другой… релизы 1-2 раз в неделю.

[7workers]

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

[glader]

Собираю файлики с sql-запросами, в базе держу номер текущей версии.

[step307]

У нас все делается вручную. В система баг-трекинга девелопер создает таск для админа с текстом sql запроса который надо выполнить.

Там кстати может быть не только расширение структуры но и фикс глючных данных, которые попали в базу из-за багов, которые только что исправлены.

Таски для ДБ так же привязываются к релизам, что и девелоперские. Соотв при выкладывании очередного релиза админ выполняет все таски.

При появлении каких-то срочных фиксов в текущий релиз — таск делается с высоким приоритетом, соотв. админ выполняет его сразу.

[DnKrozz]

Есть такая штука migrations
Изначально была в рельсах, сейчас есть во многих других фреймворках, можно и самому простой вариант написать.
Смысл в том что изменения делаются в виде файлов версий в которых прописывается up и down секция, для приведения к данной версии и для того чтобы откатится обратно. В базе хранится текущая версия.
Скрипт проверяет какие файлы версий есть и какая версия в базе и запускает последовательно эти файлики чтобы привести базу к последней версии или к указанной в параметрах.
Таким образом можно базу не только апдейтить но и даунгрейдить до нужной версии.

[Psih]

EMS DB Comparer for MySQL — мне нравиться