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

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

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

— Сначала снимите профиль нагрузки: какие таблицы пишутся чаще всего, где длинные транзакции, какие индексы критичны. Золотое правило: сначала мониторинг, потом индексы.
— Делайте перенос порциями и проверяйте контрольные суммы/счётчики строк не только в конце, а по ходу. Иначе расхождение найдёте уже после cutover, когда чинить дороже.
— Для потока изменений нужен либо CDC, либо двусторонняя логика догонки. Без этого вы получите тихую потерю данных или вечный лаг между системами.

Посмотрим, что тут с I/O в реальности. Самый частый источник простоя — не сама миграция, а блокировки: массовые UPDATE, перестроение индексов, долгие foreign key-check’и, неудачный batch size. В продакшене так лучше не делать, и вот почему: одна тяжёлая транзакция может положить и старую, и новую систему сразу.

Перед переключением обязательно прогоните репетицию cutover: заморозка записи, финальная догонка, сверка, быстрый rollback-план. Если откат не описан пошагово, это не план, а надежда.

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