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