Данные и миграции

Определи режим и инварианты

Разделяй анализ/план, подготовку миграции, репетицию и применение к целевой системе. Разрешение подготовить миграцию не означает разрешение изменить production. Уже выданное разрешение на конкретную операцию не запрашивай повторно.

Установи источник, приёмник, версию схемы, объём, владельцев чтения/записи, окно совместимости и допустимый простой. Зафиксируй инварианты: ключи, ссылки, уникальность, NULL, точность чисел, валюты, часовые пояса, Unicode и порядок событий. Не выбирай случайно одну из конфликтующих записей без правила разрешения конфликта.

Стратегия

Для небольшой локальной конвертации используй новый выходной файл и проверку, сохранив оригинал. Для живой схемы оцени expand → backfill → switch → contract: старые и новые потребители должны сосуществовать в заявленном окне. Учитывай блокировки и размер транзакций; поддержка transactional DDL зависит от СУБД и версии, её нужно проверить.

Backfill делай ограниченными партиями со стабильным ключом, checkpoint и определённым поведением при повторе. Изменения источника во время копирования требуют snapshot, change capture или согласованного окна остановки записи. Обычный COUNT не доказывает сохранность содержимого.

Восстановление

Перед разрушительной стадией проверь наличие восстанавливаемой копии и репетицию восстановления на изолированном окружении. Определи точку необратимости. Down-миграция не возвращает потерянные значения автоматически: различай rollback приложения, обратное преобразование данных, restore и roll-forward. При неизвестном исходе останови зависимые стадии и сверяй фактическое состояние, а не запускай всё повторно.

Проверки

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

Готовность зависит от режима: для анализа — установлены инварианты, риски и пробелы; для подготовки — создана миграция и план проверок, а неисполненные проверки отмечены; для репетиции — получены результаты сверки и восстановления на изолированных данных; для применения — подтверждены разрешение, фактическое состояние целевой системы и соответствующие критерии сверки. Не требуй выполненной production-операции от задачи «только подготовить план». Если нет целевой СУБД, сообщи, какие проверки локальные и что требуется до применения. Не объявляй production-миграцию выполненной по сгенерированному SQL.