Сообщить об ошибкеКороткий ответ
Если миграция уже необратимо изменила данные (например, удалила колонку или данные), простой `kubectl rollout undo` вернёт старый код, но он несовместим с новой схемой и упадёт ещё сильнее — в этом случае обычно безопаснее forward-fix: быстро задеплоить исправление поверх новой схемы (а не откат кода), либо, если это возможно, восстановить совместимость схемы отдельной компенсирующей миграцией, и только потом разбираться с откатом кода при необходимости.
Как это работает подробнее
откат Deployment откатывает только код пода, а не состояние базы данных — если миграция уже выполнила `DROP COLUMN` или необратимо преобразовала данные, старый код, ожидающий прежнюю схему, не сможет работать ни с восстановленным, ни с текущим состоянием базы без дополнительных действий. Решение зависит от конкретной ситуации: иногда возможна компенсирующая миграция (воссоздать колонку и восстановить данные из бэкапа/лога), иногда единственный путь — быстро исправить баг в новом коде и задеплоить поверх новой схемы.
Пример кода
Релиз: удалена колонка orders.legacy_status, код v2.0 больше её не использует
Инцидент: в v2.0 обнаружен баг в расчёте статуса заказа
Откат на v1.9 невозможен "просто так": v1.9 ожидает колонку legacy_status, которой больше нет
Решение: forward-fix — патч в v2.0.1, исправляющий баг расчёта статуса,
задеплоен поверх текущей (уже изменённой) схемы без отката кода.Что использовать на практике
- На практике. этот случай — главная причина, почему миграции рекомендуют делать по expand-contract с разделением на отдельные релизы: необратимый `contract`-шаг (удаление) должен выполняться только после подтверждённой стабильности `expand`-шага. Если инцидент уже произошёл, первым делом нужно оценить реальную обратимость (есть ли бэкап/snapshot перед миграцией, логично ли восстановление) и явно решить, сколько данных и функциональности можно позволить себе временно потерять ради скорости восстановления.
- Пример. Ожидаемое поведение: после деплоя v2.0.1 ошибки прекращаются без необходимости восстанавливать удалённую колонку; инцидент разбирается постфактум с выводом о необходимости expand-contract для будущих релизов с удалением данных.
Подводные камни
- Частые ошибки. автоматически реагируют на любой плохой релиз откатом Deployment, не проверив совместимость со схемой БД, усугубляя инцидент; не делают снапшот/бэкап перед необратимой миграцией, лишая себя пути восстановления в принципе.