Миграция данных без простоя: что проверить до запуска, а не после падения

Миграция данных без простоя: что проверить до запуска, а не после падения

Коллеги, давайте разберем план выполнения. Миграция ломается не на копировании, а на мелочах: несовпадение схемы, долгие блокировки, триггеры, которые внезапно начинают писать «куда не надо», и забытый backfill, который держит I/O в красной зоне.

Перед переносом проверьте три вещи: — порядок применения изменений к схеме и данным; — как идет запись во время синка: через dual-write, очередь или заморозку; — есть ли откат, который реально откатывает, а не просто «возвращает надежду». Если таблица большая, режьте перенос на батчи и следите за лагом репликации, а не за красивым прогресс-баром.

Отдельно смотрите на блокировки: онлайн-миграция, которая берет table lock на минуту, в продакшене превращается в простой на полчаса. Схема простая, но дьявол кроется в статистике: после заливки обновите статистику и проверьте план на новых данных, иначе оптимизатор выберет самый дорогой путь к счастью.

Перед cutover заранее прогоните тест на отказ: оборвать процесс, повторить запуск, сверить контрольные суммы и число строк, проверить, что приложение корректно переживает краткий разрыв соединения. Золотое правило: сначала мониторинг, потом индексы.

Если миграция не умеет безопасно повторяться и быстро откатываться, это не миграция, а лотерея с вашей базой.