Базы данных
Миграции схемы: тест с выбором ответа
Суть Тест с выбором на синтез по всему юниту: lock-queue freeze, перезапись при ADD COLUMN, NOT VALID/VALIDATE, expand-contract, WAL-флуд бэкфилла и порядок деплоя.
Высота — путь к senior
НольJuniorMiddleSenior
Ты на senior-высоте — в орбитеШесть вопросов поперёк всего юнита. Каждый отражает решение, которое ты принимаешь, выкатывая изменение схемы на живую базу под трафиком — не определение для заучивания, а режим отказа, от которого надо защититься.
Цель
Убедись, что связываешь поведение блокировок, безопасные DDL-перезаписи, фазы expand-contract, радиус поражения бэкфилла и порядок деплоя — тот синтез, к которому вели семь уроков.
Викторина
Completed
На PG 16 деплой выполняет statement ниже, и он завершается за 8 мс, но таблица users возвращает 503 в течение 70 секунд. На users уже выполнялся 60-секундный аналитический SELECT, когда сработал ALTER. Что на самом деле заморозило таблицу? ```sql ALTER TABLE users ADD COLUMN status TEXT DEFAULT 'active'; ```
Heads-up Константный дефолт мгновенен начиная с PG 11 — он хранится в pg_attribute.attmissingval, ни одна строка не пишется. Время 8 мс доказывает, что перезаписи не было; заморозка пришла из очереди блокировок, а не из работы со строками.
Heads-up Postgres никогда не вытесняет другую сессию ради миграции. ALTER ждёт за удерживаемым ACCESS SHARE; он не может его отменить. Заморозка — это FIFO-очередь, а не приоритетное вытеснение.
Heads-up Пул исчерпался, потому что новые SELECT застряли в очереди блокировок за ALTER. Миграция — непосредственная причина через очередь блокировок, а не совпадение.
Викторина
Completed
Тот же мгновенный ALTER из вопроса 1 продолжает таймаутиться за долгими запросами. Какое одно изменение превращает «миграция замораживает базу» в «миграция логирует ошибку и ретраит»?
Heads-up statement_timeout ограничивает, сколько statement выполняется после получения lock — он ничего не делает с ожиданием в очереди. Заморозка очереди — это проблема получения lock, поэтому рычаг — lock_timeout. Миграции нужны оба, по разным причинам.
Heads-up Обёртка в транзакцию не сокращает ожидание lock; ALTER всё равно стоит за удерживаемым ACCESS SHARE всю длительность блокирующего запроса. Транзакция управляет лишь временем удержания после получения, а оно уже было 8 мс.
Heads-up Больше соединений — это лишь больше сессий, копящихся за ALTER в очереди блокировок; таблица всё ещё заморожена для новых читателей. Это маскирует симптом и может усугубить затор.
Викторина
Completed
Нужно добавить FOREIGN KEY к таблице orders на 100M строк, не блокируя записи. Какой подход production-безопасен?
Heads-up Обычный ADD CONSTRAINT берёт ACCESS EXCLUSIVE и сканирует всю таблицу внутри этого lock — записи заблокированы на время скана независимо от часа. Непиковое окно уменьшает радиус, но не убирает блокировку.
Heads-up Проверки на уровне приложения гонятся под конкуренцией и дрейфуют от схемы; они не дают той же гарантии. Паттерн NOT VALID + VALIDATE добавляет настоящий constraint без блокировки записей, так что нет причин ослаблять гарантию.
Heads-up Lock ACCESS EXCLUSIVE удерживается весь валидирующий скан, в явной транзакции он или нет. Короткая транзакция не помогает; помогает разбиение на NOT VALID + VALIDATE.
Викторина
Completed
Rolling-деплой переименовывает users.username в users.handle. Чтобы и старая, и новая версии приложения работали в каждый момент, какой порядок шагов верен?
Heads-up Во время rolling-деплоя старые поды всё ещё ссылаются на username; в момент коммита переименования они получают ошибки «column does not exist». Rename быстр, но ломает инвариант совместимости с обеими версиями — именно этот сбой и предотвращает expand-contract.
Heads-up Dual-write в ещё не существующую колонку падает, а дроп username сразу после бэкфилла убивает старые поды, ещё читающие его. Contract должен ждать, пока ни один работающий код не ссылается на старую колонку.
Heads-up Дроп username, пока старые поды его читают, ломает их немедленно — это тот же сбой однашагового rename, только с лишними шагами. Expand и contract должны быть разделены полными выкатками кода.
Викторина
Completed
Бэкфилл выезжает одним statement на таблице в 100M строк. На связке primary + 2 реплики что ломается первым и какой устойчивый фикс? ```sql UPDATE users SET handle = username WHERE handle IS NULL; ```
Heads-up Единый UPDATE не дедлочится сам с собой. Радиус поражения — WAL-флуд и вызванный им replication lag на standby, а не дедлок на primary.
Heads-up У Postgres нет механизма троттлить DML по влиянию на репликацию — он выполняет UPDATE и затапливает WAL. Ограничение радиуса поражения — задача инженера через батчинг.
Heads-up Реплики реплеят WAL последовательно; десятки ГБ нельзя потребить мгновенно. Lag растёт, и standby-чтения возвращают устаревшие данные — ровно тот сбой, который предотвращает батчинг.
Викторина
Completed
Три реплики Kubernetes стартуют одновременно, и каждая выполняет migrate up при запуске. Одна успешна; две падают с ошибками дублирования объекта. Чего не хватало и какой более чистый production-паттерн?
Heads-up Миграции не идемпотентны по умолчанию — CREATE TABLE или ADD COLUMN падает при повторном применении. Падение — ожидаемый итог гонки трёх раннеров без lock, а не баг инструмента.
Heads-up Postgres понятия не имеет, что три сессии — логически один набор миграций; он выполняет каждую независимо, и они сталкиваются. Сериализацию обеспечивает раннер через advisory lock.
Heads-up Уникальный constraint останавливает двойные вставки в журнал, но сам DDL всё равно ошибается на проигравших подах и зацикливает их в рестартах. Фикс — сериализовать раннеры, в идеале вообще убрать из старта подов.
Итог
Сквозная линия юнита — один защитный чек-лист для каждого изменения схемы. Блокировки: большинству DDL нужен ACCESS EXCLUSIVE, и FIFO-очередь превращает один медленный запрос в заморозку таблицы — SET lock_timeout, чтобы неудачная попытка прервалась и ретраила. Перезаписи: константный дефолт мгновенен с PG 11, volatile-дефолты всё ещё перезаписывают. Constraints и индексы: NOT VALID + VALIDATE и CREATE INDEX CONCURRENTLY берут SHARE UPDATE EXCLUSIVE и оставляют DML работающим. Ломающие изменения: expand-contract держит старый и новый код совместимыми в каждый момент, никогда не одношаговый rename. Бэкфиллы: батчь, чтобы ограничить WAL-флуд и replica lag. Раннеры: сериализуй advisory lock’ом и гейти pre-deploy job перед выкаткой. Каждый ответ сводится к одному инварианту — схема должна оставаться совместимой с обеими версиями кода, в каждый момент, не замораживая таблицу.