Миграция данных без простоя: где чаще всего рвётся план и как это прикрыть
Коллеги, давайте разберем план выполнения. Миграция ломается не на «копировании данных», а на мелочах вокруг него: блокировки, отставание репликации, несовпадение схемы, фоновые джобы и забытые триггеры.
Рабочая схема простая:
— сначала инвентаризация зависимостей: таблицы, внешние ключи, представления, ETL, отчёты;
— потом прогон на копии с замером времени, I/O и объёма журналирования;
— затем backfill отдельными пачками, а не одним длинным транзактом;
— переключение только после проверки контрольных сумм, счётчиков и выборки по ключевым бизнес-колонкам.
Самая частая ошибка — тащить всё в один большой коммит. Он красиво выглядит в плане, но в продакшене так лучше не делать: журнал растёт, блокировки держатся дольше, откат становится болезненным. Если таблица горячая, режьте перенос на чанки и закладывайте паузы на конкуренцию с онлайн-нагрузкой.
Золотое правило: сначала мониторинг, потом индексы. Смотрите на длительность чтения, очередь на диске, ожидания блокировок и лаг реплики. Если после прогонки метрики поплыли, миграция ещё не готова, даже если данные «уже на месте».
Проверка до переключения дешевле, чем ночной откат с ручным спасением.
Оптимизация производительности баз
@database_performance_tuning_arb
Миграция данных без простоя: где чаще всего рвётся план и как это прикрыть
Этот пост опубликован в Telegram-канале Оптимизация производительности баз. Подписаться можно по ссылке: @database_performance_tuning_arb.