Миграции без простоя
Вопрос
Как вы выкатываете изменения схемы базы без простоя сервиса?
Попробуйте сами
Ответьте вслух за 2 минуты, как на собесе. Потом сверьтесь с тезисами: что прозвучало, а что нет.
Показать ответ и разбор
Коротко
Что должно прозвучать в ответе
Код и схема совместимы с предыдущей версией: rolling deploy и откат
Expand/contract: добавить, перенести, переключить, удалить отдельным релизом
Опасные операции: NOT NULL, смена типа, обычный CREATE INDEX
CONCURRENTLY для индексов, NOT VALID и VALIDATE для ограничений
Перенос данных пачками отдельно от DDL
lock_timeout и контроль долгих транзакций
Что могут спросить следом
- Как быть, если миграция упала на середине?
- Применяете миграции до или после выкладки кода?
Разбор
Образцовый ответ: «Главный принцип: в каждый момент база должна работать и со старой, и с новой версией кода, потому что при rolling deploy они живут одновременно, а ещё нужен быстрый откат. Поэтому любое ломающее изменение разбиваю по схеме expand/contract. Например, переименование колонки: добавляю новую nullable-колонку, выкатываю код, который пишет в обе, переношу данные пачками фоновой командой, переключаю чтение, а старую колонку удаляю отдельным релизом через неделю. Знаю опасные операции PostgreSQL: обычный CREATE INDEX блокирует запись, поэтому только CONCURRENTLY в неатомарной миграции; NOT NULL на большой таблице через CHECK NOT VALID и VALIDATE; смену типа колонки через новую колонку. Любой DDL может встать в очередь за долгой транзакцией и подвесить всю таблицу, поэтому ставлю lock_timeout и повторяю. Миграции применяю до выкладки нового кода, раз схема обратно совместима. Тяжёлые переносы данных не держу в одной транзакции с DDL».
Ответьте сами, а не прочитайте
В тренажёре вопрос попадёт в повторения и вернётся, когда начнёт забываться. Плюс билеты с зачётом: 20 вопросов, не больше 2 ошибок.