@Macbet
Linux программист

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

Такой вопрос, как реализуется "незаметное" обновление клиента давно известно, а как реализовать это для СУБД, приведу пример.
Имеем приложение на любом популярном языке/фреймворке, мы собрали контейнер, поставили в него все нужные пакеты и все подготовили, потом идёт обновление старая версия ещё работает, новая подготавливается и вот тут возникает вопрос. А как быть с СУБД ? Если начать обновлять миграции (например) на текущую базу то клиент получит 503-ю и весь смысл теряется. Если делать мастер-стендбай и катать миграции на стендбае то теряется персистентность... Кто сталкивался с такой проблемой?
  • Вопрос задан
  • 414 просмотров
Решения вопроса 1
Melkij
@Melkij
PostgreSQL DBA
Вы должны разрабатывать и деплоить приложение соответствующим образом. Так, чтобы старая версия приложения могла работать с новой версией схемы базы. Или наоборот, новая версия приложения могла работать со старой схемой базы.
То есть удаление таблички: сначала деплоите приложение, которое уже не работает с этой таблицей, потом удаляете таблицу
Новая табличка: сначала миграция, затем приложение
Новое поле в таблице с default значением: сначала поле, затем приложение
Новое поле без default: сначала новое поле с default null, затем релиз приложения которое обязано писать новое поле, но ещё не читать его (либо приводить null к нужному если это возможно на приложении), затем миграция с проставлением нужного значения (и, блин, не одним update по всей большой таблице), drop default, set not null, деплой приложения со всей логикой
И так далее. Во время разработки думаем, а как, когда и в сколько итераций это можно будет задеплоить.

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

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

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