Миграция схемы базы данных без простоя: expand, backfill и contract

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

«Без простоя» здесь означает отсутствие запланированной остановки сервиса. Это цель, а не гарантия: блокировки DDL, рост репликационной задержки или ошибка backfill всё равно требуют заранее проверенного пути остановки и отката.

Начните с совместимости версий

До изменения таблицы опишите, какие версии приложения будут одновременно работать во время rolling deployment. Старая версия должна продолжать читать прежнюю схему, а новая — корректно переживать отсутствие ещё не заполненных значений.

Согласуйте изменение с правилами версионирования API-контрактов: база данных тоже является контрактом между процессами, задачами и аналитическими потребителями. Переименование колонки в один шаг нарушает этот контракт так же, как удаление поля из публичного API.

Для каждого шага зафиксируйте:

• владельца и окно выполнения;
• максимальное время блокировки;
• допустимую задержку реплик;
• метрики успеха и остановки;
• порядок отмены;
• версии приложений, совместимые со схемой.

Шаг 1. Expand: добавьте новое, не удаляя старое

Создайте новую колонку, таблицу или индекс так, чтобы существующий код продолжал работать. Новое поле сначала допускает NULL или имеет безопасное значение по умолчанию. Ограничение NOT NULL и удаление старой структуры появятся позже.

На больших таблицах заранее проверьте поведение конкретной СУБД: одна и та же команда может быть мгновенным изменением метаданных в одной версии и полной перезаписью таблицы в другой. Индексы создавайте online/concurrently, если платформа это поддерживает, и ограничивайте время ожидания блокировки.

Шаг 2. Записывайте в обе модели

Новая версия приложения начинает заполнять и старое, и новое представление. Предпочтительно держать эту логику в одном транзакционном пути, а не в двух независимых запросах без проверки результата.

Двойная запись добавляет риск расхождения. Считайте ошибки каждого направления отдельно и регулярно сравнивайте значения. Если операция частично завершилась, повтор должен быть идемпотентным.

Шаг 3. Перенесите исторические данные

Backfill запускают небольшими порциями по стабильному ключу. Каждая порция имеет предел времени, контролирует нагрузку и может безопасно повториться. Не используйте один огромный UPDATE, который удерживает блокировки, раздувает журнал транзакций и создаёт всплеск репликации.

Наблюдайте за:

• скоростью обработки строк;
• CPU, I/O и размером transaction log;
• задержкой реплик;
• временем блокировок и очередью соединений;
• числом несовпадающих и необработанных записей;
• влиянием на пользовательские запросы.

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

Шаг 4. Переключайте чтение поэтапно

После заполнения данных новая версия может читать новую модель для небольшой доли трафика. Сравнивайте результат со старым чтением в фоне, но не отправляйте два ответа пользователю. Расхождения группируйте по причине, версии приложения и диапазону данных.

Увеличивайте долю только при стабильных метриках. Флаг переключения должен возвращать чтение на старую модель без новой поставки кода. Если две модели имеют разную семантику, заранее определите, какая из них является источником истины на каждом этапе.

Шаг 5. Contract: удаляйте после периода наблюдения

Старую колонку, таблицу и двойную запись удаляют только после того, как:

1. все активные версии приложения читают новую модель;
2. backfill завершён и проверен;
3. фоновые задачи и аналитика больше не используют старую схему;
4. прошёл согласованный период наблюдения;
5. откат приложения уже не требует старого формата.

Удаление — отдельная миграция и отдельный релиз. Такой разрыв делает изменения обратимыми на самой рискованной стадии переключения.

Подготовьте остановку и восстановление

Откат не всегда означает обратную миграцию DDL. Часто безопаснее остановить backfill, вернуть чтение на старую модель и оставить добавленные объекты на месте до разбора. Попытка срочно удалить их во время инцидента создаёт ещё одну тяжёлую операцию.

В операционном runbook укажите команды остановки, ответственных, пороги репликационной задержки, способ проверить целостность и условия продолжения. Репетиция на копии production-данных должна воспроизводить объём, распределение значений и конкурентную нагрузку.

Миграция схемы без запланированного простоя — это последовательность совместимых состояний. Expand создаёт место для нового формата, backfill переносит историю, контролируемое переключение подтверждает результат, а contract убирает старое только после доказательства, что оно больше не нужно.