Автор: Дмитрий Алтунин в Инфраструктура — 03 сент. 2025

Почему миграции в Percona XtraDB Cluster 8.0 могут приводить к падению кластера

В высоконагруженных кластерах Percona XtraDB обнаружен баг: при миграции через pt-online-schema-change узлы могут аварийно завершаться, запись блокироваться, а подключение новых узлов — срываться. Проблема устранена только в версии 8.0.42, обновление критично для продакшена.

При миграциях баз данных в продакшене мы ожидаем, что инструменты вроде pt-online-schema-change обеспечат минимальные риски и стабильность. Однако в Percona XtraDB Cluster 8.0 (версии 8.0.33–8.0.41) был обнаружен критический баг, приводящий к сбоям узлов, блокировке записи и нарушению работы кластера под нагрузкой. В этом посте разбираем причины проблемы, её проявления и рекомендации для безопасной миграции.

Баг представляет критическую проблему в высоконагруженных инсталляциях Percona XtraDB Cluster, вызывающую MDL BF-BF конфликты при выполнении миграции через pt-online-schema-change. Проблема может проявляться в аварийном завершении случайных узлов кластера с ошибками metadata lock conflicts, активации Flow Control и невозможности подключения узлов через Incremental State Transfer (IST). Баг затрагивает версии 8.0.33-8.0.41, и исправлен только в PXC 8.0.42 (и 8.4.5).

Данный баг был описан, воспроизведён и решён в рамках обращений к Percona.

Корневая причина связана с нарушением стандартной семантики MySQL metadata locking в пользу приоритетной модели Galera кластера. При одновременном выполнении высокоприоритетных DDL операций (RENAME TABLE) и активных INSERT/UPDATE-транзакций на таблицах с внешними ключами возникает ситуация, когда две BF (bruteforce-bruteforce) транзакции пытаются прервать друг друга, что приводит к защитному механизму кластера — аварийному завершению узла или невозможности осуществлять запись из-за работы Flow Control.

Техническое описание возникновения проблемы

Последовательность критических событий начинается с выполнения pt-online-schema-change (версия 3.7.0), который после нескольких успешных итераций копирования данных инициирует финальную RENAME TABLE операцию. В этот момент RENAME требует эксклюзивных metadata locks на все участвующие таблицы, включая связанные через внешние ключи.

MDL BF-BF (metadata lock bruteforce-bruteforce) конфликты возникают когда Galera присваивает высокий приоритет как DDL операции через TOI (Total Order Isolation), так и репликационным транзакциям от других узлов. Когда одна BF транзакция пытается прервать другую BF транзакцию, кластер обнаруживает невозможность разрешения конфликта стандартными методами и выбирает аварийное завершение узла над потенциальным нарушением консистентности данных. Но из-за механизма Flow Control не может откатить транзакцию и циклически все ноды могут уйти в защиту от записи.

Роль внешних ключей критически важна — таблицы с FK требуют дополнительных сертификационных ключей в write-set, блокировок в определенном порядке и более сложного параллельного применения транзакций. Это создает дополнительные точки конфликта между metadata locks разных транзакций в высоконагруженной среде. То есть увеличивает вероятность триггера MDL конфликтов.

Flow Control и проблемы IST

Flow Control активируется когда узел не успевает применять репликируемые транзакции со скоростью их поступления. MDL конфликты блокируют применение транзакций, вызывая рост очереди wsrep_local_recv_queue. При превышении порога gcs.fc_limit (по умолчанию 100) кластер включает механизм регулирования потока, замедляя запись на всех узлах.

IST (Incremental State Transfer) нарушается поскольку требует совпадения UUID состояния кластера и наличия всех недостающих write-sets в gcache подключающегося узла. MDL конфликты и связанные с ними Flow Control ситуации могут привести к переполнению gcache или рассинхронизации UUID, делая IST невозможным и заставляя узлы использовать полный SST (State Snapshot Transfer).

Каскадный эффект проявляется когда узел в состоянии Joined не может применить транзакции из-за MDL блокировок, вызывает Flow Control, который замедляет всех остальных участников кластера, потенциально приводя к общей деградации производительности или полной остановке репликации.

Затронутые версии и исправления

Затронутые версии включают PXC 8.0.33-25, 8.0.35-27, 8.0.36-28, 8.0.37-29 и 8.0.41, что может охватывать большое количество современных production развертываний. Версии до 8.0.33 не упоминались и не тестировались.

Исправление доступно в PXC 8.0.42 и MySQL 8.4.5, но следует планировать миграцию с учётом совместимости и тестирования.

Обходные пути и рекомендации при миграциях

При wsrep_OSU_method=TOI миграции производить через инструмент pt-online-schema-change - об этом заявляет Percona в документации

Единственно верным вариантом при использовании pt-online-schema-change является обновление PXC до версии 8.0.42, в которой баг был исправлен.

Всё остальное на текущий момент может лишь снизить вероятность возникновения проблемы с деградацией кластера, так как операция RENAME всё ещё может попасть в окно взаимоблокировок.

Альтернативный гарантированный workaround для неисправленных версий — полная остановка записи во время выполнения DDL операций, что делает его неприемлемым для высокодоступных production систем.

Настройки pt-online-schema-change могут включать:

--max-flow-ctl=15 (процентов) для приостановки операций при превышении Flow Control
--chunk-size=1000 и --chunk-time=0.5 для минимизации блокировок (значения можно подбирать в зависимости от нагрузки)
--alter-foreign-keys-method=rebuild_constraints для безопасной обработки внешних ключей

Параметры для диагностики (ведёт к дополнительноый нагрузке на дисковую подсистему):

wsrep_log_conflicts=ON — логирование конфликтов для анализа
wsrep_debug=ON — только для кратковременной диагностики (высокая нагрузка на I/O)

Потенциально опасные изменения, которые встречались на форумах. Использовать на свой страх и риск!

wsrep_slave_threads — начать с текущего значения × 1.5, но не более числа CPU ядер
- Слишком мало = медленное применение транзакций
- Слишком много = больше конфликтов при параллельном применении
wsrep_retry_autocommit=3 — умеренное увеличение (default=1)
- Помогает при откатах, но увеличивает нагрузку при конфликтах
gcs.fc_limit=32 (снижение с 100) — более агрессивный Flow Control может УХУДШИТЬ ситуацию
Отключение wsrep_max_ws_rows/wsrep_max_ws_size — риск OOM и зависаний при больших транзакциях
gcs.fc_factor - изменение может дестабилизировать синхронизацию узлов

Симптомы и условия проявления

Данный баг воспроизводился во время миграций через pt-online-schema-change на продуктовой нагрузке как при 25к QPS, так и при 5к QPS (в менее нагруженное время).
Проблема возникает на финальной стадии во время выполнения RENAME TABLE для подмены мигрированной таблицы на замену той, над которой выполнялась миграция.

Структурные предпосылки включают таблицы с внешними ключами, одновременную высокую нагрузку INSERT/UPDATE операций, и выполнение DDL операций через pt-online-schema-change. Временные факторы показывают что проблема проявляется не сразу, а после нескольких итераций с непредсказуемым характером — любой узел может стать жертвой конфликта.

В логах могут встречаться следующие записи:

Спам сообщениями вида:

[Warning] [MY-000000] [Galera] client_state: Unallowed state transition: result -> quit

Не выполняющиеся откаты транзакций:

[Note] [MY-000000] [WSREP] Wsrep_rollback_local

MDL BF-BF конфликты:

[Note] [MY-000000] [WSREP] MDL BF-BF conflict

schema:  epay
request: (thd-tid:10 	seqno:1234 	exec-mode:high priority, query-state:exec, conflict-state:executing)
          cmd-code:3 167 	query:(null))

granted: (thd-tid:2 	seqno:1235 	exec-mode:toi, query-state:exec, conflict-state:committed)
          cmd-code:3 167 	query:RENAME TABLE `test` TO `_test_old`, `_test_new` TO `test`)

Мониторинг

Мониторинг критических метрик должен включать отслеживание wsrep_flow_control_paused_ns, wsrep_local_recv_queue, состояния metadata locks через Performance Schema таблицу metadata_locks, и логов с паттерном MDL BF-BF conflict, Wsrep_rollback_local, Unallowed state transition: result -> quit.

Диагностические запросы для выявления проблем:

-- Мониторинг Flow Control
SHOW STATUS LIKE 'wsrep_flow_control%';

-- Поиск MDL блокировок  
SELECT OBJECT_SCHEMA, OBJECT_NAME, LOCK_TYPE, LOCK_STATUS 
FROM performance_schema.metadata_locks 
WHERE OBJECT_NAME = 'target_table';

-- Заблокированные процессы
SELECT ID, STATE, INFO FROM information_schema.processlist 
WHERE STATE = 'Waiting for table metadata lock';