MySQL InnoDB Cluster с Group Replication: отказоустойчивая БД для бизнеса

Привет! Я, Семёнов Евгений Сергеевич, директор ITFresh. Знаете, в моём багаже — больше пятнадцати лет работы с базами данных, особенно с корпоративными инфраструктурами. Последние восемь лет я буквально живу MySQL Group Replication. Когда клиенту нужен по-нанастоящему надёжный, отказоустойчивый MySQL, и при этом он не готов переплачивать за коммерческие лицензии, мой выбор всегда один — InnoDB Cluster. Почему? Да потому что это не просто родное решение; им невероятно просто управлять через MySQL Shell, а самое главное — он даёт полностью автоматический failover, причём за считанные секунды! В этой статье я хочу провести вас через весь процесс: от того, какое железо лучше выбрать, до запуска в прод, включая тонкости мониторинга и, конечно, бэкапов.

Зачем InnoDB Cluster и чем он лучше master-slave

Знаете, классическая асинхронная репликация MySQL из нулевых — это, по моему опыту, настоящее слабое звено в любой системе. Мастер вдруг падает? Вы рискуете потерять последние транзакции. А failover? Его приходится делать руками, и процесс promotion нового мастера требует ювелирной аккуратности. Ошибка здесь, кстати, часто стоит очень дорого — можете попрощаться с данными. Group Replication, к счастью, решает все эти проблемы раз и навсегда.

• Синхронная репликация с кворумом. Транзакция коммитится, только если её подтвердило большинство узлов.
• Автоматический failover. При падении primary оставшиеся узлы выбирают нового через Paxos-подобный протокол.
• Согласованность данных. Никаких split-brain, никаких расхождений.
• Горизонтальное масштабирование чтения. Приложение раздаёт SELECT по secondary-узлам.
• Онлайн-расширение. Добавление нового узла — без остановки кластера.

Требования к серверам

Чтобы группа работала надёжно, узлов должно быть нечётное количество — 3, 5 или 7. Лично я почти всегда останавливаюсь на трёх узлах: этого вполне хватит, чтобы защититься от падения одного сервера. А большего для большинства корпоративных задач обычно и не нужно.

Сеть — это критично, без малейших преувеличений. Group Replication крайне чувствителен к задержкам: если между узлами лаг до 2 мс, всё в порядке. Но стоит ему перевалить за 10 мс, и ждите серьёзного падения производительности. На нашей практике бывали случаи, когда клиенты размещали узлы в разных регионах. И что в итоге? Медленный кластер, который, честно говоря, эффективнее было бы заменить на старую добрую асинхронную репликацию.

Подготовка узлов

Мы обычно предпочитаем Ubuntu 22.04 LTS или RHEL 9. На каждом узле, естественно, ставим MySQL 8.0 из официального репозитория, а потом очень тщательно настраиваем конфиг под требования Group Replication. Это важно.

# /etc/mysql/mysql.conf.d/mysqld.cnf — на всех 3 узлах
[mysqld]
server_id = 1  # 1, 2, 3 соответственно
bind_address = 0.0.0.0
port = 3306
log_bin = mysql-bin
gtid_mode = ON
enforce_gtid_consistency = ON
binlog_format = ROW
binlog_checksum = NONE
transaction_write_set_extraction = XXHASH64
relay_log_info_repository = TABLE
master_info_repository = TABLE
innodb_buffer_pool_size = 48G
innodb_log_file_size = 2G
innodb_flush_log_at_trx_commit = 1
sync_binlog = 1
performance_schema = ON
report_host = db01.corp.local  # db02, db03

По файрволу всё просто: открываем порты 3306 (SQL) и 33061 (Group Replication transport) между узлами. Остальное — только для приложений.

Инициализация кластера через MySQL Shell

MySQL Shell — это современно и, пожалуй, самый удобный способ управлять InnoDB Cluster. Мы ставим его либо на отдельную админскую машину, либо прямо на один из узлов кластера.

mysqlsh --uri root@db01.corp.local:3306

# Проверка готовности узла
dba.configureInstance('root@db01.corp.local')
dba.checkInstanceConfiguration('root@db01.corp.local')

# Создание кластера на первом узле
var cluster = dba.createCluster('ProdCluster', {
  memberSslMode: 'REQUIRED',
  ipAllowlist: '192.168.10.0/24',
  localAddress: 'db01.corp.local:33061'
});

# Добавление второго и третьего узла
cluster.addInstance('root@db02.corp.local:3306', {
  recoveryMethod: 'clone',
  localAddress: 'db02.corp.local:33061'
});
cluster.addInstance('root@db03.corp.local:3306', {
  recoveryMethod: 'clone',
  localAddress: 'db03.corp.local:33061'
});

# Статус
cluster.status();

Метод clone копирует начальный дамп с primary за пару минут на SSD. Без него узел будет догонять через binlog — это долго, если база большая.

MySQL Router: прокси для приложений

Это важно запомнить: приложениям нельзя подключаться к MySQL напрямую. Иначе при failover они просто не смогут перехватить смену primary. Вот почему мы ставим MySQL Router: его можно разместить либо на тех же хостах, где работают приложения, либо выделить для него отдельные машины.

apt install -y mysql-router

mysqlrouter --bootstrap root@db01.corp.local:3306 \
  --directory /etc/mysqlrouter \
  --conf-use-sockets \
  --account router_user

systemctl enable --now mysqlrouter

После запуска Router начинает слушать два порта: 6446 для чтения-записи (он направляет запросы на primary) и 6447 для read-only (распределяет нагрузку по secondary методом round-robin). Приложение коннектится как обычно, а Router сам всё разруливает, и голова не болит.

Тюнинг под production

Скажу честно, дефолтные настройки MySQL 8 далеки от идеала. Мой подход? Всегда правлю:

• innodb_buffer_pool_size — 70–75% RAM сервера.
• innodb_io_capacity — для NVMe ставлю 20000, для SATA SSD — 2000.
• innodb_flush_method = O_DIRECT — отключает двойное кэширование ОС.
• group_replication_consistency = BEFORE_ON_PRIMARY_FAILOVER — гарантирует, что новый primary отдаёт только committed данные.
• max_connections = 2000 — плюс pool на стороне приложения.
• CPU governor всегда в performance, swappiness = 1, THP — строго в madvise.

Кейс: 1С + Битрикс24 на кластере

Вспомним один кейс: сентябрь 2025 года, к нам обратился крупный ритейлер обуви — 120 магазинов по стране. Их просьба? Убрать единую точку отказа, или SPOF, из MySQL. Раньше у них стояла одна-единственная база на Dell R640. Представьте: вечер пятницы, она падает! Результат: четыре часа простоя и, что самое обидное, полмиллиона рублей убытков. Мы действовали быстро: собрали три узла на Dell PowerEdge R750xa (каждый с Xeon Platinum 8280, 256 ГБ RAM, 4 × 2 ТБ NVMe RAID-10 и 40G Mellanox). Разместили их в дата-центре МТС в Москве, прямо в одной стойке с клиентским приложением. Развернули InnoDB Cluster в конфигурации single-primary, а MySQL Router поставили на четырёх фронтах. Что по результатам? По нашим наблюдениям, время failover составило от 8 до 14 секунд. За полгода с момента запуска мы зафиксировали два автоматических failover во время плановых обновлений, ноль ручных вмешательств и, что самое главное, ноль простоев. Сейчас база весит 380 ГБ, а пиковая нагрузка доходит до 3400 TPS. Просто огонь!

Мониторинг и обслуживание

# Состояние кластера
cluster.status();
cluster.describe();

# Быстрая проверка из SQL
SELECT * FROM performance_schema.replication_group_members;
SELECT * FROM performance_schema.replication_group_member_stats;

Prometheus-экспортер mysqld_exporter в связке с дашбордом Percona PMM дают нам полный контроль: видно всё — репликация, InnoDB buffer pool, медленные запросы. Алерты настроены на всё: любой сбой кворума, рост отставания на secondary, катастрофическое уменьшение свободного места.

• Ежедневно мы делаем бэкап с secondary, используя Percona XtraBackup. Это наш стандарт.
• Еженедельно — проверка целостности GTID.
• Каждый месяц наша команда проводит критически важную процедуру — поочерёдное обновление всех узлов. Зачем? Чтобы внедрить актуальные улучшения и патчи, не прерывая работу ваших сервисов: это называется rolling upgrade. Мы гарантируем, что система будет стабильно функционировать, пока идёт апгрейд. Важно ведь, чтобы всё работало без остановки, правда?
• Четыре раза в год, то есть ежеквартально, мы проводим серьёзные учения. Это не просто формальность. В чём их суть? Мы намеренно инициируем принудительное падение primary-узла. Звучит жёстко, но это критически важно! Мы обязаны убедиться, что в случае реальной нештатной ситуации система мгновенно и без сбоев переключится на резервные мощности. Такая «тренировка» гарантирует быстрое восстановление и непрерывность работы ваших сервисов. Спокойствие клиента — наш главный приоритет, поэтому мы репетируем всё до мелочей.

FAQ — MySQL InnoDB Cluster

Чем InnoDB Cluster отличается от классической репликации?

InnoDB Cluster использует Group Replication — синхронную репликацию с кворумом и автоматическим выбором мастера. Классическая async-репликация требует ручного failover и не гарантирует консистентность при падении мастера.

Сколько узлов нужно минимум?

Три узла — минимум для кворума. Допускается до 9 узлов в группе. Для большинства корпоративных задач оптимум — 3 узла.

Что делает MySQL Router?

MySQL Router — прокси-слой между приложением и кластером. Он знает топологию, направляет запись на primary, чтение — на secondary, и автоматически переключается при failover.

Single-primary или multi-primary?

Для корпоративных баз 1С, Bitrix, CRM я всегда выбираю single-primary: меньше конфликтов, проще отладка.

Как делается бэкап?

Штатно — MySQL Enterprise Backup или Percona XtraBackup с secondary-узла. Это не нагружает primary и даёт горячий бэкап без блокировок.