Как выполнить миграцию схемы без простоя (zero-downtime), например переименование колонки, при rolling deploy, когда старая и новая версия приложения работают одновременно?

Короткий ответ

Прямое переименование колонки одной миграцией несовместимо с rolling deploy, так как старая версия кода ещё обращается к старому имени; безопасный подход — паттерн expand/contract: добавить новую колонку, синхронизировать данные со старой, переключить код на новую, и только после полной раскатки удалить старую колонку отдельной миграцией.

Как это работает подробнее

Во время rolling deploy одновременно работают как минимум две версии кода, обращающиеся к одной БД — любое несовместимое изменение схемы должно оставаться совместимым с обеими версиями кода на протяжении переходного периода.

Пример кода

example.sqlКопировать

-- Шаг 1 (релиз N): добавить новую колонку
ALTER TABLE users ADD COLUMN full_name TEXT;
-- Приложение версии N пишет в обе колонки: name и full_name
-- Backfill исторических данных батчами
UPDATE users SET full_name = name WHERE full_name IS NULL AND id BETWEEN 1 AND 50000;
-- Шаг 2 (релиз N+1, после полной раскатки N): код читает только full_name
-- Шаг 3 (релиз N+2, после подтверждения): удалить старую колонку
ALTER TABLE users DROP COLUMN name;

Что использовать на практике

• Практика. Для переименования: expand (добавить колонку) → dual write (приложение пишет в обе колонки) → backfill исторических данных → переключение кода на чтение новой колонки → contract (удаление старой колонки отдельным релизом).

Подводные камни

• Ошибка. Выполняют ALTER TABLE RENAME COLUMN в одной миграции одновременно с деплоем нового кода, полагая, что деплой происходит мгновенно — старые инстансы тут же начинают падать с ошибкой «колонка не существует».