Comments 14
1. Никогда не меняю ничего в имеющейся структуре так, чтобы это могло привести к потере данных. Только расширения и модификации.
2. Вследствие этого спокойно меняю структуру на продакшне без боязни что-то ломать.
3. Потом mysqldump | mysql — и изменения с продакшна у меня на тестовом вместе со свежими данными.
4. Вношу нужные правки в код тестового и отлаживаю его.
5. Коммичу изменения кода тестового на продакшн.
2. Вследствие этого спокойно меняю структуру на продакшне без боязни что-то ломать.
3. Потом mysqldump | mysql — и изменения с продакшна у меня на тестовом вместе со свежими данными.
4. Вношу нужные правки в код тестового и отлаживаю его.
5. Коммичу изменения кода тестового на продакшн.
Всю базу дампить можно при маленьком ее размере… а если 10 гигов?
Такие объёмы обычно бывают на базах с уже устоявшейся структурой. Любые ковыряния с ней, независимо в каком порядке — форммажор. Они могут вылиться в часы простоя продакшна. К изменению структур в таких БД готовятся заранее и тщательное планируют время модификации (обычно что-нибудь глубокой ночью с субботы на воскресенье).
…
У меня на форуме база сообщений всего 3,5Гб, и то каждая модификация — это СОБЫТИЕ. Одно только перестроение индексов при ALTER TABLE идёт минут по 40.
…
У меня на форуме база сообщений всего 3,5Гб, и то каждая модификация — это СОБЫТИЕ. Одно только перестроение индексов при ALTER TABLE идёт минут по 40.
Я всегда стараюсь держать структуру базы в репозитории — например, так — для каждой таблицы файлик с CREATE TABLE, тоже самое для хранимых процедур триггеров. Но вот автоматизировать, имхо это не стоит. Если при откате скрипт сделает ALTER TABLE DROP column — у меня могут потеряться данные в каком-то поле — может я временно отктатился, а потом вернусь назад, а даных то уже нет. Так что лучше уж сразу планировать БД так, что бы она не приводила к конфликтам. А поводу инкрементального развития(новые поля, таблицы) можно дописывать в репозиторий ALTER TABLE`ы(вы ведь их все равно у себя делаете) а потом выполнять их на продакшене.
Еще не разу не откатывался после изменения структуры базы. Каждое такое изменение очень тщательно продумываем. Никто, конечно, не застрахован. С интересом буду следить за комментариями :-) Вдруг пригодится.
всегда синхронизирую вручную, да и делать это приходится всего несколько раз за проект. Если вам нужно делать это через день — у вас не production, а ещё один dev-сервер по-моему.
Собираю файлики с sql-запросами, в базе держу номер текущей версии.
У нас все делается вручную. В система баг-трекинга девелопер создает таск для админа с текстом sql запроса который надо выполнить.
Там кстати может быть не только расширение структуры но и фикс глючных данных, которые попали в базу из-за багов, которые только что исправлены.
Таски для ДБ так же привязываются к релизам, что и девелоперские. Соотв при выкладывании очередного релиза админ выполняет все таски.
При появлении каких-то срочных фиксов в текущий релиз — таск делается с высоким приоритетом, соотв. админ выполняет его сразу.
Там кстати может быть не только расширение структуры но и фикс глючных данных, которые попали в базу из-за багов, которые только что исправлены.
Таски для ДБ так же привязываются к релизам, что и девелоперские. Соотв при выкладывании очередного релиза админ выполняет все таски.
При появлении каких-то срочных фиксов в текущий релиз — таск делается с высоким приоритетом, соотв. админ выполняет его сразу.
Есть такая штука migrations
Изначально была в рельсах, сейчас есть во многих других фреймворках, можно и самому простой вариант написать.
Смысл в том что изменения делаются в виде файлов версий в которых прописывается up и down секция, для приведения к данной версии и для того чтобы откатится обратно. В базе хранится текущая версия.
Скрипт проверяет какие файлы версий есть и какая версия в базе и запускает последовательно эти файлики чтобы привести базу к последней версии или к указанной в параметрах.
Таким образом можно базу не только апдейтить но и даунгрейдить до нужной версии.
Изначально была в рельсах, сейчас есть во многих других фреймворках, можно и самому простой вариант написать.
Смысл в том что изменения делаются в виде файлов версий в которых прописывается up и down секция, для приведения к данной версии и для того чтобы откатится обратно. В базе хранится текущая версия.
Скрипт проверяет какие файлы версий есть и какая версия в базе и запускает последовательно эти файлики чтобы привести базу к последней версии или к указанной в параметрах.
Таким образом можно базу не только апдейтить но и даунгрейдить до нужной версии.
EMS DB Comparer for MySQL — мне нравиться
Sign up to leave a comment.
Синхронизация структуры MySQL