@nomadictionn

Как правильно деплоить mysql базу/миграции?

Добрый день. Изучаю CI/CD, и возник такой вопрос.

В процессе разработки у нас меняется структура БД.
Мы прописываем эти изменения в миграции (не важно, хоть в Laravel Migration, хоть просто sql-файл с `alter table`).
Отправляем эти миграции на сервер вместе с докер-образом.
Запускаем их - они делают в базе нужные `alter table`.

И вроде все замечательно, но возникает такая проблема: насколько я понимаю, суть всего этого процесса в быстром/незаметном (для юзеров) смене версий кода на живом сервере.
Если у нас миграция простая (создать/удалить таблицу) - то она выполняется быстро, и всё хорошо.

Но что делать в случае, если в процессе разработки у нас меняется что-то в таблице на миллионы строк?
Тогда миграция будет применяться долго, и при этом заблокирует всю работу с приложением.

Обычно в таких случаях я лезу на сервер и делаю `pt-online-schema-change`, но что делать для "правильного" CI/CD?

Единственное что я могу сейчас придумать:
1. поднимаем параллельно второй инстанс БД с копией продакшен базы;
2. накатываем миграции на этот инстанс;
3. синхронизируем данные, которые успели измениться за это время на старом инстансе, с новым;
4. тушим старый инстанс, оставляем новый и меняем контейнер с php-кодом, который теперь будет с ним работать;

Но мне кажется, это какая-то не очень правильная схема - гонять две копии огромной БД.
  • Вопрос задан
  • 190 просмотров
Решения вопроса 1
Fockker
@Fockker Куратор тега PHP
Потомок старинного рода Ипатьевых-Колотитьевых
Если это не хайдлоад, то есть 95% всех случаев, то никакой проблемы и нет, альтеры отработают быстро.
В остальных случаях примерно такая схема и применяется, только непонятно, зачем всю базу-то гонять.
https://github.com/github/gh-ost
https://docs.percona.com/percona-toolkit/pt-online...
Ответ написан
Пригласить эксперта
Ответы на вопрос 3
saboteur_kiev
@saboteur_kiev
software engineer
Обычно в таких случаях я лезу на сервер и делаю `pt-online-schema-change`, но что делать для "правильного" CI/CD?


В правильном CI/CD таких изменений быть не должно. Задача архитектора - создать приложение, которое легковесно и без проблем как деплоится, так и откатывается.
Задача девопс инженера - автоматизировать деплой и откат разными инструментами.
Понятно, что все могут работать вместе и разрабатывать какой-то флоу, но если разработчики приходят с такими процессами, тут нет волшебных ci/cd инструментов которые сделают тяжелую задачу мгновенной.

Если вы не можете повлиять на решение девелоперов и архитекторов, то не важно - любое рабочее решение, которое вы придумаете в пределах вашей инфраструктуры будет норм. И две базы, и релиз по ночам и что-нибудь еще.
Но DevOps как культура как раз и говорит, что надо менять подход к работе, а не взять крутого человека, который возьмет весь бардак, засунет его в какой-нить ансибл/дженкинс, подключит плагин с AI и все порешается без изменений.
Ответ написан
@vitaly_il1
DevOps Consulting
Насколько понимаю, правильно избегать "тяжелых" модификаций, которые блокируют базу. Иначе действительно нет элегантного способа накатить миграцию.
Ответ написан
Комментировать
dimonchik2013
@dimonchik2013
non progredi est regredi
Единственное что я могу сейчас придумать:
1. поднимаем параллельно второй инстанс БД с копией продакшен базы;
2. накатываем миграции на этот инстанс;
3. синхронизируем данные, которые успели измениться за это время на старом инстансе, с новым;
4. тушим старый инстанс, оставляем новый и меняем контейнер с php-кодом, который теперь будет с ним работать;

примерно все как вы описали, но, видимо, вас никогда не били за потерю данных
таблицу стараются не менять до последнего - проще сделать рядом таблицу исключений / дополнений и в приложении дополнительную проверку
(это если изначально она не была спроектирована очень уж плохо)
когда уже нельзя терпеть - делается таблица рядом, наполняется и приложение переключается на нее ,или rename саму таблицу
Ответ написан
Комментировать
Ваш ответ на вопрос

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

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