Мигрируем БД в продакшене без даунтайма
Основной совет, который даётся в статье — нужно разбивать деплой новой фичи на 2 и более части, чтобы соблюсти обратную совместимость. Это очень важно, если для выкатки новой фичи необходимо изменить схему базы данных.
Обратная совместимость необходима, потому что во время деплоя в кластере будут одновременно инстансы со старой версий и обновлённой версией приложения, и нам необходимо обеспечить их одновременную бесперебойную работу.
Например, если требуется удалить поле из БД, нужно выполнять деплой в 2 захода:
- Удаляем весь код, работающий с этим столбцом — деплоим
- Удаляем столбец и снова — деплоим
Если бы мы удаляли одновременно поле и код, взаимодействующий с кодом, то мы бы столкнулись с ситуацией, когда старые версии, всё ещё будут пытаться обращаться к этому полю, но так как поле удалено — это может привести к даунтайму.
В нашем случае, такой ситуации не случится, так как к моменту удаления столбца, все инстансы в кластере обновлены и больше не взаимодействуют с полем, теперь его можно удалить.
https://habr.com/ru/post/664028/