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

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

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

Чтобы не лечить прод с выключенным светом, держите базовый чек-лист: • заранее сравнить схемы и типы; • прогнать объёмную загрузку на копии; • отдельно проверить уникальности, FK и NULL-ограничения; • продумать обратный откат, а не только «переключение»; • замерить, что будет с журналом, репликацией и I/O под пиком.

Посмотрим, что тут с I/O в реальности. Полный залив часто упирается не в CPU, а в запись: растёт журнал, раздуваются чекпоинты, блокируются горячие страницы. Для больших таблиц безопаснее батчи с контролем пауз, а не один монолитный INSERT. И да, отключение индексов ради скорости помогает только если вы умеете потом быстро и без сюрпризов их пересобрать.

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

Лучший способ избежать простоя — не надеяться на «авось», а заранее прогнать миграцию как инцидент: с репетицией, таймингами и планом отката.