{"id":14272,"url":"\/distributions\/14272\/click?bit=1&hash=9c431bca9c7cafdd4ed114bc7fb4d407f06f28aa165d6f80b9637d3a8581e5c2","title":"\u0421\u0431\u0435\u0440\u041a\u043e\u0442 \u2014 \u043f\u0435\u0440\u0432\u044b\u0439 \u0446\u0438\u0444\u0440\u043e\u0432\u043e\u0439 \u0438\u043d\u0444\u043b\u044e\u0435\u043d\u0441\u0435\u0440, \u043a\u043e\u0442\u043e\u0440\u044b\u0439 \u043f\u043e\u043b\u0435\u0442\u0435\u043b \u0432 \u043a\u043e\u0441\u043c\u043e\u0441","buttonText":"","imageUuid":""}

Мигрируем БД в продакшене без даунтайма

Основной совет, который даётся в статье — нужно разбивать деплой новой фичи на 2 и более части, чтобы соблюсти обратную совместимость. Это очень важно, если для выкатки новой фичи необходимо изменить схему базы данных.

Обратная совместимость необходима, потому что во время деплоя в кластере будут одновременно инстансы со старой версий и обновлённой версией приложения, и нам необходимо обеспечить их одновременную бесперебойную работу.

Например, если требуется удалить поле из БД, нужно выполнять деплой в 2 захода:

  • Удаляем весь код, работающий с этим столбцом — деплоим
  • Удаляем столбец и снова — деплоим

Если бы мы удаляли одновременно поле и код, взаимодействующий с кодом, то мы бы столкнулись с ситуацией, когда старые версии, всё ещё будут пытаться обращаться к этому полю, но так как поле удалено — это может привести к даунтайму.

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

https://habr.com/ru/post/664028/

0
Комментарии
-3 комментариев
Раскрывать всегда