Таксономия сбоев миграций и дисциплина продакшна

Шесть месяцев после внедрения pipeline миграций у команды не было инцидентов с очередью блокировок. Затем обновление бэкфила генерирует 40 ГБ WAL за десять минут — лаг репликации достигает 120 секунд, чтения из standby устаревают, и две read-реплики возвращают строки, противоречащие друг другу. Миграция прошла нормально; вокруг неё упала база.

Девять режимов отказа миграций

WAL-наводнение бэкфила подробно

Наивный бэкфил запускает один большой UPDATE:

-- НИКОГДА не делать этого на большой таблице:
UPDATE users SET handle = username WHERE handle IS NULL;

На 100 млн строк это генерирует запись WAL (Write-Ahead Log) для каждой обновлённой строки — потенциально 20–50 ГБ WAL за минуты. Реплики должны потребить этот WAL перед обслуживанием чтений; лаг репликации вырастает до минут и более. В это окно standby read-реплики возвращают устаревшие данные. Если лаг превышает max_standby_streaming_delay, Postgres отменяет конфликтующие запросы на standby.

Устойчивое исправление: пакеты по 1к–10к строк с пространством для дыхания:

DO $$
DECLARE
  batch INT;
BEGIN
  LOOP
    UPDATE users SET handle = username
    WHERE handle IS NULL
      AND ctid IN (
        SELECT ctid FROM users WHERE handle IS NULL LIMIT 5000
      );
    GET DIAGNOSTICS batch = ROW_COUNT;
    EXIT WHEN batch = 0;
    PERFORM pg_sleep(0.1);
  END LOOP;
END $$;

Мониторьте SELECT * FROM pg_stat_replication — следите, чтобы sent_lsn - replay_lsn оставалось около нуля во время бэкфила.

Дрейф схемы на репликах

Миграция, применённая на primary, распространяется на реплики через потоковую репликацию. Лаг репликации (нормальный диапазон: менее 1 с; под нагрузкой: 5–30 с) означает, что реплики могут видеть старую схему секунды после коммита миграции. Если код деплоится до нагона репликации:

• Read-реплики обслуживают запросы к старой схеме.
• Новый код, ожидающий новую колонку, получает NULL или ошибки от standby-чтений.

Устойчивое исправление: блокировать раскатку кода до приближения лага репликации к нулю. Мониторьте через pg_stat_replication.replay_lag на primary. В pre-deploy проверках большинства инструментов миграций включён запрос к replica-lag.

Squawk CI и стратегическая позиция по миграциям

Squawk (Linux Foundation) парсит SQL миграции и предупреждает или выдаёт ошибки на небезопасных паттернах:

• ADD COLUMN with volatile DEFAULT → ошибка
• ALTER COLUMN TYPE без проверки совместимости типов → ошибка
• CREATE INDEX без CONCURRENTLY → ошибка
• RENAME COLUMN / TABLE → предупреждение
• DROP COLUMN без подтверждения предварительного деплоя кода → предупреждение

Запускайте Squawk на каждом PR, затрагивающем migrations/**. Стоимость: менее 30 с на PR с миграцией. Польза: ловит наиболее распространённые режимы отказа до слияния.

Стратегическая позиция: относитесь к коду миграций с той же дисциплиной, что к коду приложения — PR-ревью, CI-lint, деплой на стейджинг на данных продакшн-размера, запись в runbook, наблюдаемость по времени выполнения и получению блокировки. Старшие команды выпускают ломающие изменения регулярно; разница в том, что каждое изменение спланировано, прочёсано линтером, наблюдаемо и поддаёт прямому откату.