Как организовать zerodowntime обновление СУБД?

Question

[Macbet]

Такой вопрос, как реализуется "незаметное" обновление клиента давно известно, а как реализовать это для СУБД, приведу пример.
Имеем приложение на любом популярном языке/фреймворке, мы собрали контейнер, поставили в него все нужные пакеты и все подготовили, потом идёт обновление старая версия ещё работает, новая подготавливается и вот тут возникает вопрос. А как быть с СУБД ? Если начать обновлять миграции (например) на текущую базу то клиент получит 503-ю и весь смысл теряется. Если делать мастер-стендбай и катать миграции на стендбае то теряется персистентность... Кто сталкивался с такой проблемой?

Comments

[vlarkanov]

Мастер-слейв репликация поможет. Старая база - мастер, новая - слейв. До последнего момента запросы идут в мастер, потом когда надо мастер выключается и запросы переводятся на слейв. Всё.

[Даша Циклаури]

vlarkanov, если требуется запись, всё?

[vlarkanov]

Даша Циклаури, то что пишется в мастер - оказывается и на слейве. Сразу после отключения мастера можно начинать писать в слейв. Зачем писать в слейв, пока из эксплуатации не выведен мастер?

[Даша Циклаури]

vlarkanov, мастер выведен из экплуатации, на нем обновляется схема, данные пишутся в слэйв, после ввода мастера как данные из слэйва будут синхронизироваться?

[vlarkanov]

Даша Циклаури, снимаем со слейва бекап, заливаем в обновленный мастер. И... делаем обновлённый мастер слейвом бывшего слейва. Когда данные затянутся - выключаем слейв, пишем в обновленный мастер.

И да, MySQL поддерживает каскадную репликацию, так что уже на этапе первоначальной настройки слейва можно ему сказать

server-id = 3
log_bin = /var/log/mysql/mysql-bin.log
binlog_do_db = база_которую_мы_реплицируем

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

Answer 1

[Melkij]

Вы должны разрабатывать и деплоить приложение соответствующим образом. Так, чтобы старая версия приложения могла работать с новой версией схемы базы. Или наоборот, новая версия приложения могла работать со старой схемой базы.
То есть удаление таблички: сначала деплоите приложение, которое уже не работает с этой таблицей, потом удаляете таблицу
Новая табличка: сначала миграция, затем приложение
Новое поле в таблице с default значением: сначала поле, затем приложение
Новое поле без default: сначала новое поле с default null, затем релиз приложения которое обязано писать новое поле, но ещё не читать его (либо приводить null к нужному если это возможно на приложении), затем миграция с проставлением нужного значения (и, блин, не одним update по всей большой таблице), drop default, set not null, деплой приложения со всей логикой
И так далее. Во время разработки думаем, а как, когда и в сколько итераций это можно будет задеплоить.

Ну и, разумеется, DBA (или заменяющий его обязанности человек) думает над тем, как именно вносить нужную миграцию в базу