Advisory-блокировки, инструменты миграций и координация деплоя

Kubernetes-деплоймент масштабируется с нуля до трёх реплик одновременно. Все три пода запускаются и каждый пытается выполнить ожидающую миграцию. Без координации все три применяют её параллельно — один успешно, два падают с ошибками дублирования constraint, приложение запускается наполовину в неизвестном состоянии.

Транзакционная семантика DDL в Postgres

Большинство DDL в Postgres транзакционный: BEGIN; CREATE TABLE; ALTER TABLE; COMMIT; либо всё выполняется, либо всё откатывается атомарно. Конкурентные сессии видят изменение только после COMMIT (изоляция снимком MVCC).

Исключения, которые не могут выполняться внутри блока транзакции:

• CREATE INDEX CONCURRENTLY
• REINDEX CONCURRENTLY
• ALTER TYPE ... ADD VALUE (в PG 11 и ниже; транзакционный начиная с PG 12+)

Инструменты миграций по умолчанию оборачивают каждую миграцию в транзакцию. Любая миграция с CONCURRENT-операцией требует аннотации нетранзакционного режима. Большинство инструментов поддерживают это:

• Atlas: -- atlas:txmode none
• golang-migrate: -- migrate:notransaction
• Prisma: не поддерживается нативно; используйте prisma db execute с raw SQL-файлом

Если вы смешиваете CONCURRENT-операцию с другим DDL в одном файле миграции — разбейте их на два файла.

Паттерн advisory-блокировки для сериализации запуска миграций

Несколько серверов приложения, запускающихся одновременно, могут каждый попытаться выполнить ожидающие миграции. Без координации два процесса могут применить одну и ту же миграцию дважды или конфликтовать на таблице schema_migrations.

Стандартное решение — advisory-блокировка Postgres в начале миграции:

-- Берётся перед выполнением любых миграций:
SELECT pg_advisory_lock(12345);  -- 12345 = стабильный целочисленный ключ для этого приложения

-- Здесь выполняются миграции ...

-- Освобождается после завершения всех миграций:
SELECT pg_advisory_unlock(12345);

pg_advisory_lock блокируется до получения блокировки. Первый сервер получает её и выполняет миграции; последующие ждут. Когда первый завершает и освобождает блокировку, следующий сервер получает её — но обнаруживает все миграции уже применёнными и ничего не делает.

Большинство инструментов миграций реализуют это автоматически:

• golang-migrate: берёт pg_advisory_lock(hashInt64(databaseName)) при запуске.
• Prisma: использует таблицу _prisma_migrations с блокировкой на уровне строк.
• Atlas: использует pg_advisory_lock с настраиваемым ключом.

Для неблокирующего поведения при запуске используйте pg_try_advisory_lock с циклом повторов:

-- Возвращает true при успешном получении, false если уже занята
SELECT pg_try_advisory_lock(12345);

Координация деплоя: миграция до раскатки подов

Три распространённых паттерна:

1. Pre-deploy job (рекомендован): k8s Job или CI-шаг запускает migrate up против продакшна до rolling deploy. Деплой кода заблокирован успехом миграции. Старые поды обрабатывают трафик во время миграции; схема аддитивна (только expand). Это чистейший паттерн — чёткое разделение ответственности.

2. Init container на каждом поде: каждый новый под запускает migrate up при запуске; advisory-блокировка их сериализует. Просто, но медленно — каждый под ждёт проверки миграции, даже если ничего не ожидает.

3. Отдельный pipeline миграций: миграция запускается вручную или в собственном ритме, полностью отвязана от деплоя кода. Требует человеческой координации; ненадёжна в масштабе.

Старший дефолт 2026: отдельный pre-deploy job (паттерн 1), заблокированный на успехе миграции. Задание миграции выдаёт метрики; любой сбой страницует on-call и блокирует раскатку кода.