Кейс: ALTER TABLE в миграции держал лок на проде дольше деплоя

Flyway накатывал миграцию с добавлением колонки NOT NULL DEFAULT на таблицу в несколько десятков миллионов строк. На старых версиях Postgres такой ALTER TABLE требует полного rewrite таблицы под ACCESS EXCLUSIVE локом — блокируются все SELECT, INSERT и UPDATE, пока идёт переписывание.

Deploy pipeline ждал завершения миграции, health check не проходил по таймауту, оркестратор перезапускал под. Миграция стартовала заново на той же таблице, лок держался ещё дольше. Со стороны выглядело как зависший деплой, хотя причина была в одной строке DDL.

Чинили в три шага: сначала добавили колонку как nullable без default — это быстрая операция без rewrite. Потом бэкфиллили значения батчами в отдельной транзакции, не блокируя основной трафик. В конце навесили NOT NULL через constraint с NOT VALID, а валидацию — отдельным быстрым шагом, который не держит лок дольше, чем на чтение.

Следом обычно спрашивают про zero-downtime миграции индексов — почему CREATE INDEX CONCURRENTLY нужен вместо обычного CREATE INDEX, и что произойдёт, если процесс миграции убьют посреди CONCURRENTLY-построения индекса.

Миграция на проде — это не DDL-скрипт, а отдельная операция с собственным SLA на лок.

Тренажёр: 600 вопросов, мок с таймером, план повторов

senior·base — что спрашивают на самом деле

В этом посте были ссылки, но мы их удалили по правилам Сетки