Orchestrator для MySQL: визуализация топологии и ручной промоут без паники

Зачем Orchestrator и почему он снимает стресс в авариях

Когда в проде крутится несколько MySQL-узлов, вам нужно ясно видеть, кто у кого реплицируется, насколько отстают реплики, какие из них готовы к промоуту, и что делать при падении primary. Orchestrator закрывает все эти задачи: даёт наглядную визуализацию topology, позволяет управлять replica chain одной кнопкой или CLI-командой, а ещё автоматизирует и документирует операции failover. Даже если вы предпочитаете ручной контроль, Orchestrator — это то, что удерживает команду от паники в горячий момент.

В статье собраны практики для админов и devops: минимальная конфигурация, права в MySQL, запуск и обнаружение инстансов, сценарии ручного промоута с GTID и без него, работа с errant-транзакциями, правила кандидатов, безопасность и операционные чеклисты. Примеры адаптированы для окружений на VDS, но подходят и для bare metal.

Термины: на одной странице

Чтобы не было путаницы:

• Primary/Writer — узел, принимающий запись (в старой терминологии master).
• Replica/Reader — узел, повторяющий транзакции (в старой терминологии slave).
• Topology — граф зависимостей репликации, дерево от primary к репликам.
• Failover — переключение записи на другой узел при аварии.
• Промоут — повышение реплики до роли primary вручную или автоматикой.
• GTID — глобальные идентификаторы транзакций, упрощающие переключения.

Подготовка окружения: сеть, доступ, учётки

Для комфортной работы Orchestrator нужен стабильный доступ ко всем MySQL-узлам по TCP 3306, одинаковые часовые пояса/время (NTP), и отдельный системный пользователь/пароль в MySQL с необходимыми правами. На VDS это обычно означает: открыть соответствующие порты в фаерволе, настроить private-сеть или VPN между базами и узлом с Orchestrator, и включить мониторинг. Для шифрования админских соединений используйте TLS; базовые принципы и выпуск собственных CA описаны в материале TLS для MySQL и PostgreSQL: CA и сертификаты.

В MySQL создайте пользователя для Orchestrator. Примеры для разных версий:

-- MySQL 5.7 / MariaDB
CREATE USER 'orchestrator'@'10.%' IDENTIFIED BY 'StrongPass!';
GRANT SUPER, PROCESS, RELOAD, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'orchestrator'@'10.%';
FLUSH PRIVILEGES;

-- MySQL 8.0+
CREATE USER 'orchestrator'@'10.%' IDENTIFIED BY 'StrongPass!';
GRANT SYSTEM_VARIABLES_ADMIN, SESSION_VARIABLES_ADMIN, RELOAD, PROCESS, REPLICATION SLAVE ADMIN, BINLOG_ADMIN, REPLICATION CLIENT ON *.* TO 'orchestrator'@'10.%';
FLUSH PRIVILEGES;

Если политика безопасности требует «минимально необходимых привилегий», можно отказаться от широкого SUPER и перейти на гранулированные роли (как в MySQL 8+). Но учтите: для корректного промоута Orchestrator должен иметь право менять read_only/super_read_only, паузить и переподключать репликацию.

Установка и базовая конфигурация

Orchestrator поставляется как один бинарник и сервис. На Linux удобнее всего поставить систему как службу и держать конфиг в /etc/orchestrator.conf.json. Пример минимальной конфигурации:

{
  "Debug": false,
  "ListenAddress": ":3000",
  "MySQLTopologyUser": "orchestrator",
  "MySQLTopologyPassword": "StrongPass!",
  "MySQLOrchestratorUser": "orchestrator",
  "MySQLOrchestratorPassword": "StrongPass!",
  "AuthenticationMethod": "basic",
  "BasicAuthUsers": {"admin": "bcrypt:$2y$12$examplehashonly"},
  "DiscoveryPollSeconds": 5,
  "InstancePollSeconds": 5,
  "ReplicationLagQuery": "select @@global.seconds_behind_master",
  "RaftEnabled": false
}

Пояснения:

• ListenAddress — веб-интерфейс и API (держите за фаерволом или за reverse proxy с TLS).
• AuthenticationMethod и BasicAuthUsers — простая аутентификация. Для продакшена добавьте TLS на балансировщике.
• DiscoveryPollSeconds и InstancePollSeconds — частота опроса метрик и топологии.
• RaftEnabled — кластерный режим самого Orchestrator (для HA самого контроллера). Для одиночного узла оставьте false.

Запустите службу и добавьте первый инстанс на обнаружение:

systemctl enable --now orchestrator
orchestrator-client -c discover -i db1:3306
orchestrator-client -c discover -i db2:3306
orchestrator-client -c discover -i db3:3306

Через веб-интерфейс вы увидите дерево репликации: кто чей источник, отставание, SQL/IO thread состояния и прочие health-индикаторы. Для безопасного доступа используйте SSH-туннель или публикацию за обратным прокси с мандатной авторизацией.

Визуализация topology: что важно смотреть каждый день

Главный экран даёт ответы: где находится primary, какие у него реплики, кто отстаёт, и какие узлы помечены в качестве кандидатов для failover. Важные признаки «здоровой» картины:

• У всех реплик Seconds_Behind_Master стремится к нулю.
• Нет красных индикаторов по IO/SQL потокам.
• Наметки promotion rule установлены осознанно: хотя бы одна реплика в том же AZ/ЦОД и с сопоставимым железом отмечена как «must» или «prefer».
• GTID включён и согласован на всех узлах, если вы используете GTID.

Золотое правило: Orchestrator — это ваш единый «источник истины» по topology. Держите его картину в актуальном состоянии, и ручной промоут станет рутинной процедурой.

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

Промоут с GTID: «мягкая» передача роли без простоя

При включённом GTID и чистой репликации самый надёжный сценарий планового промоута — graceful takeover. Он аккуратно фиксирует старый primary, догоняет выбранную реплику, переключает трафик репликации и открывает запись на новом узле.

# Отметьте лучшую реплику как кандидата
orchestrator-client -c set-promotion-rule -i db2:3306 -promotion-rule must

# Плановый промоут с паузой записи на старом primary
orchestrator-client -c graceful-master-takeover -i db1:3306

1. Переводит старый primary в read_only/super_read_only, чтобы прекратить новые транзакции.
2. Дожидается, пока кандидат полностью догонит журнал транзакций.
3. Переключает остальных реплик на нового primary.
4. Ставит старый primary в режим реплики.

В окнах обслуживания это самый предсказуемый путь: нет ручных CHANGE REPLICATION SOURCE TO, минимальный «ступор» для приложения, и вся процедура задокументирована в журнале Orchestrator. Дополнительно про параметры GTID и semi-sync см. заметку GTID, semi-sync и устойчивый failover.

Без GTID: Pseudo-GTID и классическая позиционная репликация

Если GTID отсутствует, Orchestrator может справляться с переключением через сопоставление координат binlog и Pseudo-GTID. Суть — периодически вставлять уникальный маркер в транзакции, чтобы находить точки совпадения.

Минимальные параметры для включения этого механизма:

{
  "UseSuperReadOnly": true,
  "DetectPseudoGTID": true,
  "PseudoGTIDPattern": "^DROP VIEW IF EXISTS _pseudo_gtid_.*$",
  "PseudoGTIDMonotonicHint": true
}

А на стороне БД — периодически исполнять безвредный SQL (через cron/сервис миграций):

-- раз в N секунд
DROP VIEW IF EXISTS _pseudo_gtid_20250101_120000;
CREATE VIEW _pseudo_gtid_20250101_120000 AS SELECT 1 AS one;

Orchestrator использует эти маркеры, чтобы быстро рассчитать «точку встречи» между репликами при переезде. Это не так надёжно, как GTID, но даёт безопасный промоут без ручных манипуляций с позициями binlog.

Errant-транзакции: главный враг промоута

Errant-транзакции — это изменения, которые попали на реплику, но не существуют на primary (например, отладочная запись на реплике). При GTID они оставляют след в gtid_executed и мешают чистому переключению.

Проверьте согласованность GTID:

-- На нескольких узлах сравните
SELECT @@global.gtid_executed\G

Если значения на кандидате «шире», чем на primary, у вас потенциальная проблема. Стратегии решения:

• Пересоздать реплику из чистого бэкапа.
• В редких случаях — точечная компенсация (только если вы чётко понимаете последствия).

Orchestrator умеет выявлять errant-узлы и помечать их как непригодные для промоута. Следите за индикаторами в UI и не назначайте такие реплики «must».

Политики кандидатов: кто «must», кто «avoid»

Чтобы в аварии не гадать, пометьте заранее узлы правилами промоушена:

# Запретить промоут слабой реплики
orchestrator-client -c set-promotion-rule -i db3:3306 -promotion-rule avoid

# Назначить основной кандидат в том же ЦОД
orchestrator-client -c set-promotion-rule -i db2:3306 -promotion-rule must

Правила учитываются как при ручном, так и при автоматическом failover. Важно: правило «must» не отменяет здравый смысл — если реплика отстаёт или сломана, Orchestrator не сделает промоут любой ценой.

Плановый промоут: сценарий без стресса

1. Проверьте здоровье репликации: нет отставаний, нет errant-транзакций.
2. Убедитесь, что приложение может пережить короткую паузу записи.
3. Пометьте кандидата правилом «must» и откройте интерфейс Orchestrator для наблюдения.
4. Выполните graceful-master-takeover.
5. Проверьте, что новый primary в super_read_only=OFF, а остальные — в read_only=ON.
6. Сделайте контрольную запись и убедитесь, что она реплицируется вниз по дереву.

Экстренный failover: когда primary уже недоступен

Если узел внезапно упал и недоступен, Orchestrator может выполнить контролируемое восстановление topology и промоут лучшего кандидата, руководствуясь правилами и «близостью» по журналам.

# Инициировать восстановление топологии относительно старого primary
orchestrator-client -c recover -i db1:3306

Алгоритм сработает так:

• Оценит реплики, исключит отстающие и с errant-транзакциями.
• Выберет кандидата (учитывая «must/prefer/avoid»).
• Переконфигурирует остальных реплик на нового primary.

Если хотите явно указать кандидата, делайте перенос реплик вручную и затем открывайте запись:

# Перенести всех потомков от db1 к db2
orchestrator-client -c relocate-replicas -i db1:3306 -d db2:3306
# Разрешить запись на db2
orchestrator-client -c set-writeable -i db2:3306

После возврата старого узла в строй переведите его в реплику и подчините новому primary. Не спешите «откатывать» промоут, пока не убедитесь в стабильности.

Репликация и настройки, о которых часто забывают

• read_only и super_read_only. Первая защита от случайной записи на читателях.
• Политика binlog_format и детерминированность триггеров/функций.
• Политика автопереключения. Если не готовы к полной автоматике, оставьте автоматический failover выключенным и тренируйте ручные сценарии.
• Полузависимая репликация (semi-sync). Она уменьшает риск потери подтверждённых транзакций при аварии, но повышает задержки записи. Тестируйте на стейджинге.

Для восстановления до точки во времени (PITR) держите проверенные бэкапы и binlog-архив. Подробно про стратегию и шаги см. материал PITR на binlog и GTID.

Безопасность Orchestrator

• Ограничьте доступ к веб-UI и API: слушать на 127.0.0.1, публиковать через обратный прокси с TLS и базовой аутентификацией.
• Минимизируйте привилегии MySQL-пользователя, но не лишайте сервис жизненно важных прав.
• Храните пароли в конфиге с правами доступа 600 и системным пользователем службы.
• Аудитируйте действия через встроенный журнал Orchestrator.

Наблюдение и алерты

Поднимите базовые метрики: задержка репликации, здоровье IO/SQL потоков, состояние узла Orchestrator, успешность последних операций topology. Алерты: «реплика отстаёт > X сек», «topology diverged», «неудачный промоут», «errant detected».

Практика для VDS: где держать Orchestrator и как ресурсы планировать

Сам Orchestrator потребляет скромно: 1 vCPU и 512–1024 МБ RAM обычно достаточно даже для десятков инстансов. Логично держать его на отдельном VDS рядом по сети с БД. Обязательно:

• Стабильные диски (журнал и кэш Orchestrator быстро не растут, но надёжность важна).
• Синхронизация времени (chrony/systemd-timesyncd).
• Фаервол с явными allow-правилами только для админских IP и подсетей БД.

Чеклист ручного промоута

• GTID включён и согласован на всех узлах, либо включён Pseudo-GTID.
• Кандидат помечен «must» или «prefer», нет errant-транзакций.
• Репликация здорова, отставание близко к 0.
• Приложение готово к короткой паузе записи.
• graceful-master-takeover для планового случая, recover — для аварийного.
• После промоута: проверка роли узлов, тестовая запись, валидность бэкапов и джобов.

Частые вопросы

Нужно ли включать автопереключение?

Зависит от SLA. Если команда всегда на связи — ручной промоут надёжнее. Если RTO считанные минуты и дежурные могут опоздать — настройте авто, но жёстко задайте правила кандидатов и протестируйте все сценарии.

Сколько реплик достаточно?

Минимум две: одна основная читательская реплика и вторая — горячий кандидат под промоут. Если читательская нагрузка высока — добавляйте отдельные узлы под аналитические запросы.

Можно ли смешивать версии MySQL/MariaDB?

Технически возможно, но переключения станут сложнее. Для безболезненного failover лучше держать совместимые версии на всех узлах одной topology.

Итоги

Orchestrator снимает ключевой риск с вашей MySQL-репликации: делает topology наглядной, промоут — управляемым, а аварии — предсказуемыми. Правильно выданные права, чистый GTID, помеченные кандидаты и отработанные процедуры превращают «ночной пожар» в спокойную техоперацию. Начните с визуализации, затем отрепетируйте плановый промоут, и только после этого включайте автоматические механизмы failover там, где это оправдано вашим SLA. На практичной инфраструктуре на VDS это даёт оптимальный баланс простоты и устойчивости.