Зачем сравнивать три подхода
Онлайн-изменение схемы в MySQL редко бывает «совсем без влияния» на прод. Обычно цель такая: провести DDL так, чтобы пользователи не заметили просадки, а команда получила предсказуемый риск и управляемый план отката.
На практике online DDL — это компромисс между временем операции, дополнительной нагрузкой (IO/CPU/redo/undo), длительностью блокировок и тем, насколько «аккуратно» всё отработает в репликации.
Самые популярные варианты:
- Native Online DDL в InnoDB:
ALTER TABLE ... ALGORITHM=INPLACEи (где возможно)ALGORITHM=INSTANT, часто сLOCK=NONE. - Percona Toolkit: pt-online-schema-change (pt-osc) — «таблица-тень + триггеры».
- GitHub: gh-ost — «таблица-тень + потоковое копирование + применение изменений из binlog», обычно удобнее в реплицируемых топологиях.
Базовая проблема: metadata lock (MDL) и почему он важнее, чем кажется
Любые DDL-операции в MySQL завязаны на MDL (metadata lock) — блокировку метаданных объекта. Даже если движок умеет «online», серверу всё равно нужно согласовать изменения схемы с конкурентными запросами.
Два типовых «подводных камня» MDL в проде:
- Очередь ожидания: если DDL ждёт MDL, новые запросы могут начать ждать его (эффект «очереди за кассой»), даже если сами могли бы отработать.
- Короткая, но критичная финальная фаза: у online-процедур есть commit/swap-момент, где блокировка должна быть взята быстро. Если в этот момент есть длинные транзакции или плотный поток DML, «секунды» легко превращаются в минуты.
Если вы хотите «без простоя», управляйте не только длительностью DDL, но и условиями, при которых MDL сможет взяться: длинными транзакциями, долгими чтениями, фоновыми джобами и паттернами автокоммита.
Для практики это означает: инструмент важен, но ещё важнее — подготовка (поиск долгих транзакций, окно по нагрузке, понятный стоп/пауза-план).
Native Online DDL: ALTER TABLE ALGORITHM=INPLACE / INSTANT
Как это работает
У InnoDB есть несколько «классов» DDL. Упрощённо:
ALGORITHM=COPY— создаётся новая таблица, данные копируются, затем переключение. Часто самый тяжёлый вариант.ALGORITHM=INPLACE— без полного копирования таблицы, но не означает «совсем без блокировок» и не гарантируетLOCK=NONEдля любой операции.ALGORITHM=INSTANT(MySQL 8.0+) — мгновенное изменение метаданных для части операций.
Хорошая практика — задавать ограничения явно, чтобы не «случайно» уйти в COPY:
ALTER TABLE t ADD COLUMN c INT, ALGORITHM=INPLACE, LOCK=NONE;Если сервер не может выполнить операцию в указанном режиме, он вернёт ошибку. В проде это обычно лучше, чем внезапная многочасовая операция с блокировками.
Плюсы
- Просто: один DDL без внешнего оркестратора.
- Минимум «магии»: нет триггеров и теневых таблиц, если не считать внутренних механизмов InnoDB.
- Репликация обычно понятная: выполняется тот же DDL на репликах (с поправкой на то, что тяжёлый DDL может замедлить SQL-thread).
Минусы и риски
- Не все изменения поддерживаются как
INPLACE/INSTANTи сLOCK=NONE. - MDL остаётся: даже при «онлайновости» есть фазы синхронизации и финальный commit, которые могут залипнуть из-за долгих транзакций.
- Ресурсы: некоторые операции создают большой объём изменений, растят redo/undo и провоцируют лаг репликации.
Когда выбирать
Если ваш ALTER гарантированно проходит как INSTANT или как INPLACE с LOCK=NONE, это обычно самый безопасный путь по простоте. Перед продом всё равно стоит проверить на похожем объёме и хотя бы приблизительно похожей нагрузке.
pt-online-schema-change: «таблица-тень + триггеры»
Механика
pt-online-schema-change создаёт «теневую» таблицу с новой схемой и ставит триггеры на исходную таблицу, чтобы все изменения (INSERT/UPDATE/DELETE) зеркалились в теневую. Дальше данные копируются батчами, а в конце выполняется атомарный swap (обычно через RENAME), после чего триггеры удаляются.
Ключевые этапы выглядят так:
- Создать новую таблицу с нужной схемой.
- Поставить триггеры на исходную таблицу.
- Скопировать данные батчами, регулируя нагрузку.
- Дождаться «догонки» изменений.
- Сделать swap и удалить служебные объекты.
Плюсы
- Работает там, где native DDL не справляется: сложные изменения, старые версии, неудобные операции.
- Управляемая нагрузка: копирование можно «душить» и адаптировать под прод.
- Прогнозируемость: часто проще оценить, сколько времени займёт копирование батчами, чем гадать про длительность тяжёлого DDL «на месте».
Минусы: цена триггеров и нюансы репликации
Главный минус pt-osc — триггеры на живой таблице:
- Оверхед на каждый DML: изменение строки фактически выполняется дважды (исходная + теневая).
- Конфликты с существующей логикой: свои триггеры, права, особенности приложений и нестандартные схемы могут внезапно «выстрелить».
- Репликация: многое зависит от формата binlog и от того, как в вашей топологии воспроизводятся триггеры и массовые операции.
И, как и везде, swap-фаза упирается в MDL: если в момент RENAME есть долгие транзакции, финал может ждать, а очередь запросов начнёт накапливаться.
Когда pt-osc оправдан
- Вы на MySQL 5.6/5.7 и нужный ALTER не укладывается в online DDL.
- Таблица очень большая, но нагрузка по записи умеренная, и вы готовы платить за триггеры.
- Вам критична возможность «паузы» и тонкой подстройки скорости копирования.
gh-ost: «миграция через binlog»
Идея
gh-ost тоже создаёт новую таблицу и копирует данные, но ключевое отличие — синхронизация изменений без триггеров: инструмент читает события из binlog (обычно с реплики или с мастера) и применяет их к теневой таблице, пока идёт копирование.
Это даёт два практических преимущества:
- Нет триггеров на исходной таблице: меньше накладных расходов на DML и меньше риска конфликтов.
- Контроль репликации: gh-ost проектировали под реплицируемые окружения, поэтому сценарии «контроль лагов, пауза, аккуратный swap» обычно ложатся в него естественнее.
Слабые места и ограничения
- Зависимость от binlog: нужны корректные настройки логирования, права, понятный источник событий.
- Операционная сложность: больше сущностей и состояний, чем у одного
ALTER TABLE. - Финальный swap всё равно требует MDL: к этому моменту нужно подготовиться (убрать длинные транзакции и «снизить турбулентность» DML).
Если ваша топология активно завязана на GTID и вам важно понимать, как миграции сочетаются с переключениями и полу-синхронной репликацией, полезно держать под рукой внутренний разбор: GTID и semi-sync: как избежать сюрпризов при failover.
Сравнение: блокировки, нагрузка, эксплуатация
Metadata lock и «момент истины»
Во всех трёх подходах есть момент, где требуется синхронизация схемы с конкурентными запросами:
- Native INPLACE/INSTANT: MDL берётся сервером; длительность зависит от типа операции и условий в момент commit.
- pt-osc: swap через RENAME требует MDL; долгие транзакции легко превращают финал в «ожидание неопределённости».
- gh-ost: swap тоже есть, но копирование/догонка отделены, поэтому обычно проще подготовить «окно» именно для финала.
Нагрузка на мастер
- INPLACE: нагрузка может быть высокой (IO/redo/undo), но она «нативная» и часто более предсказуемая по профилю операции.
- pt-osc: копирование плюс постоянная цена триггеров на DML; на горячих таблицах это часто решающий минус.
- gh-ost: копирование плюс применение изменений из binlog; на мастере обычно меньше оверхеда, чем у триггеров, но важно следить за лагом и ресурсами узла, который читает/обрабатывает события.
Replication safety
Здесь полезно разделять «сломать репликацию» и «получить большой лаг/дрейф из-за перегруза и очередей».
- INPLACE/INSTANT: проще всего концептуально — один DDL воспроизводится на репликах, но тяжёлый DDL может сильно замедлить их.
- pt-osc: триггеры и массовые операции увеличивают вероятность неожиданностей, особенно при сложных настройках binlog/репликации.
- gh-ost: обычно удобнее именно в реплицируемых средах, но требует дисциплины в настройках и мониторинге.
Для углубления в восстановление и PITR (когда изменения схемы «соседствуют» с восстановлением по binlog) пригодится разбор: PITR из binlog/GTID: как не потерять точку восстановления.
Операционная сложность
- INPLACE/INSTANT: минимальная сложность, максимальная зависимость от возможностей конкретной версии MySQL и конкретного ALTER.
- pt-osc: средняя сложность, но много «граблей» вокруг триггеров, прав и особенностей таблиц.
- gh-ost: сложнее в эксплуатации, но часто даёт лучший контроль и меньше вмешательство в горячий DML.
Если админки или панели мониторинга доступны по сети (даже во внутреннем контуре), лучше закрывать их корректным TLS: подберите подходящие SSL-сертификаты и не откладывайте обновление цепочек.
Как выбрать метод: практическая матрица
Если нужно быстро принять решение для прода, используйте такую последовательность:
- Проверьте INSTANT (MySQL 8.0+) или возможность выполнить
ALGORITHM=INPLACEсLOCK=NONE. Если да — чаще всего это лучший вариант по простоте и рискам. - Если online DDL не подходит, а таблица не «горячая» по записи — pt-online-schema-change может быть проще внедрить и объяснить команде.
- Если таблица «горячая», оверхед триггеров неприемлем, и у вас корректно настроен binlog/репликация — чаще всего выигрывает gh-ost.
- В любом случае заранее спланируйте работу с MDL: найдите и устраните длинные транзакции и процессы, которые держат блокировки метаданных.
Что обязательно проверить перед онлайн-миграцией
Длинные транзакции и «висящие» чтения
Самый частый источник «неожиданного простоя» — долгоживущие транзакции. В том числе чтения под консистентным снапшотом: они могут мешать финальной фазе DDL/swap. Важно иметь понятную процедуру: как быстро найти проблемный коннект, как остановить отчётный джоб, какие лимиты по времени выполнения запросов приемлемы.
План отката
Для native DDL откат часто означает «делать обратный ALTER», что бывает долго или невозможно без компромиссов. Для gh-ost/pt-osc концептуально проще остановиться до swap, но нужно заранее понимать, что делать с теневой таблицей и как вернуть приложение в исходный режим без ручной паники.
Мониторинг лагов и ресурса
«Без простоя» в реальности часто означает «без падения сервиса, но с деградацией»: рост latency, IOwait, лаг репликации. Должны быть метрики и право/возможность остановить процесс, если он выходит за пределы.
Тест на реалистичном объёме
Тест на маленькой таблице почти ничего не доказывает. Важно приближать объём данных, профиль индексов и интенсивность записи к боевым условиям.
Итог
Выбор между gh-ost, pt-online-schema-change и нативным ALTER TABLE INPLACE/INSTANT лучше делать не по «модности», а по трём вопросам: поддерживает ли ваша версия MySQL нужный режим online DDL, сколько вы готовы платить в нагрузке на запись, и насколько критична предсказуемость репликации.
INPLACE/INSTANT — лучший первый вариант по простоте. pt-osc — рабочая классика, но триггеры могут стать узким местом. gh-ost — часто самый аккуратный путь для горячих таблиц и реплицируемых топологий, если вы готовы к более сложной эксплуатации. А MDL остаётся общей точкой риска: успех онлайн-миграции почти всегда начинается с контроля транзакций и дисциплины по нагрузке.
Если вы выкатываете изменения схемы на отдельный сервер базы (в тесте или проде), удобнее делать это на изолированном VDS, а для админок и мониторинга не забывайте про корректные SSL-сертификаты для внутренних панелей.
