Миграция данных без простоя: где чаще всего ломают план и теряют ночь

Миграция данных без простоя: где чаще всего ломают план и теряют ночь

Коллеги, давайте разберем план выполнения. Миграция падает не на копировании, а на недооценке хвоста: блокировки, триггеры, фоновые джобы, репликация, расхождение схемы. Если переносите большой объем, сразу разделяйте задачи: сначала совместимость схемы, потом перенос данных, потом переключение.

Рабочий минимум перед cutover:
— сверить типы, nullable, дефолты и индексы;
— отключить или изолировать записи, которые могут менять данные во время заливки;
— заранее проверить, как поведут себя FK, триггеры и каскады;
— прогнать обратный откат: не «на словах», а реальным скриптом.

Посмотрим, что тут с I/O в реальности. Частая ошибка — делать финальную синхронизацию под полной нагрузкой без лимитов и окон. В итоге источник задыхается, приемник не успевает, а бизнес видит не миграцию, а красиво оформленный простой. Схема простая, но дьявол кроется в статистике: если не знаете скорость дельты, не знаете и время простоя.

Для безопасного переключения держите план с двумя ветками: штатный путь и быстрый rollback. Перед финалом заморозьте записи, проверьте контрольные суммы или выборочную сверку ключевых таблиц, потом переключайте трафик. И да — запускать миграцию без репетиции на копии базы в продакшене так лучше не делать, и вот почему...

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