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

Question

[nomadictionn]

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

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

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

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

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

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

Но мне кажется, это какая-то не очень правильная схема - гонять две копии огромной БД.

Answer 1

[Ипатьев]

Если это не хайдлоад, то есть 95% всех случаев, то никакой проблемы и нет, альтеры отработают быстро.
В остальных случаях примерно такая схема и применяется, только непонятно, зачем всю базу-то гонять.
https://github.com/github/gh-ost
https://docs.percona.com/percona-toolkit/pt-online...

Comments

[nomadictionn]

> непонятно, зачем всю базу-то гонять

У меня откуда-то в голове взялась аксиома, что я не могу в докер-контейнере с базой делать "мелкие" операции, могу либо всё, либо ничего. Сейчас после вашего ответа я-то понимаю, что это глупость какая-то, и мне нет разницы - слать в него SELECT * FROM из пхп или ALTER TABLE из pt-online-schema-change. ¯\_(ツ)_/¯

Спасибо.

Answer 2

[Saboteur]

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

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

Если вы не можете повлиять на решение девелоперов и архитекторов, то не важно - любое рабочее решение, которое вы придумаете в пределах вашей инфраструктуры будет норм. И две базы, и релиз по ночам и что-нибудь еще.
Но DevOps как культура как раз и говорит, что надо менять подход к работе, а не взять крутого человека, который возьмет весь бардак, засунет его в какой-нить ансибл/дженкинс, подключит плагин с AI и все порешается без изменений.

Comments

[nomadictionn]

> В правильном CI/CD таких изменений быть не должно

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

> DevOps как культура как раз и говорит, что надо менять подход к работе

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

Если вписать pt-online-schema-change в какой-нить ансибл/дженкинс - это неправильный подход, то как тогда делают?

[Ипатьев]

nomadictionn, здесь много таких персонажей, который приходят не на вопрос ответить, а на себя полюбоваться

[Saboteur]

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

Да.
Изменение структуры базы может идти как нестандартные миграционные работы, их можно и не включать в CI/CD, а делать для них отдельный мануальный релиз.
Ведь нужно предусмотреть возможность отката, а это в некоторых случаях практически невозможно, проще фулл бэкап делать.

Если вписать pt-online-schema-change в какой-нить ансибл/дженкинс - это неправильный подход, то как тогда делают?

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

Если вы заранее знаете, что структура у вас всегда будет меняться примерно одинаково, можете и автоматизировать. Но тогда не было бы такого вопроса.

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

[nomadictionn]

> Если вы заранее знаете, что структура у вас всегда будет меняться примерно одинаково, можете и автоматизировать. Но тогда не было бы такого вопроса.

Я допускаю, что в 95% случаев изменения в структуре будут следующими:
- добавить новую таблицу - очевидно, с этим проблем нет никаких, но это всё ещё подпадает в категорию "изменение структуры";
- добавить (именно добавить) в поле типа enum новое значение - с этим тоже никаких проблем;
- добавить колонку в таблицу среднего размера (100к строк) - это уже какой-то даунтайм на выполнение alter, но тоже не очень сложно звучит;

Поэтому мне и было интересно, как все эти случаи - разные между собой в деталях, но одинаковые по сути - уживаются в "правильном" процессе ci/cd. Чтобы понять для себя принцип, как строить процесс для разных ситуаций с базой.

Поэтому спасибо вам за ответы тоже

[nomadictionn]

> отдельное событие релиза с миграцией, где этот шаг либо выполняют вручную

А как это реализуется в случае того же скрипта в Github Actions, например?

[Saboteur]

Окей. За последние 10 лет добавление новой колонки и тем более добавление нового столбца у нас встречались единичные случаи. Для этого просто в небизнес время добавляли колонку руками, добавляли столбец руками - даунтайм для этого вообще не нужен, просто идет какое-то время, если база большая.
Опять таки 100к строк это в общем-то не миллионы, если железо тянет, то это минутное дело может быть.
А деплой идет уже после того, как нужные вещи есть.

Если же нужно именно вплести в деплойпроцесс, то просто один из шагов - применить sql файл.
Для мелких изменений мы сделали директорию, где был main.sql, и различные release_yyyymmdd.sql
Задача разработчиков была добавить нужный releasexxx.sql и в main.sql закомментировать старый, добавить новый.

при каждом релизе применяется main.sql, где выполняются нужные ddl команды.
Задача разработчика (точнее dba разработчика), написать их re-runnable
например, создать отдельную таблицу "версий", куда добавлять что уже было применено, и соответственно выполнять проверку, чтобы не делать повторное действие. Если оно недеструктивное, например просто выводит варнинг что xxx already exists - можно без проверки, но в таблице все равно заводится запись, что такого-то числа был применен xxx.sql - удобно для возможной отладки/проверки.

Ну и все.

Answer 3

[Vitaly Karasik]

Насколько понимаю, правильно избегать "тяжелых" модификаций, которые блокируют базу. Иначе действительно нет элегантного способа накатить миграцию.

Answer 4

[Dimonchik]

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

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