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

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

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

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

Перед переключением проверьте не объём, а поведение: есть ли длинные транзакции, блокировки на запись, перестроение индексов, бэкграунд-воркеры, которые лезут в старую схему. Посмотрим, что тут с I/O в реальности: часто именно оно превращает «быстрый cutover» в многочасовой простой.

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