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

Семёнов Евгений Сергеевич, директор АйТи Фреш. 15+ лет работаю с базами данных в корпоративных инфраструктурах, из них последние 8 лет плотно с MySQL Group Replication. Я всегда выбираю InnoDB Cluster, когда заказчику нужна отказоустойчивая MySQL без покупки коммерческих решений: он нативен, прост в управлении через MySQL Shell и даёт автоматический failover за секунды. В этой статье разберу полный цикл — от выбора железа до продакшена с мониторингом и бэкапами.

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

Классическая асинхронная репликация MySQL из нулевых — это слабое звено. При падении мастера вы теряете последние транзакции, failover делается руками, promotion нового мастера требует аккуратности и ошибки часто стоят данных. Group Replication решает эти проблемы на корню.

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

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

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

Сеть — критично. 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

После bootstrap Router слушает два порта: 6446 для чтения-записи (идёт на primary) и 6447 для read-only (round-robin по secondary). Приложение коннектится как обычно, 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 — падение вечером пятницы стоило им 4 часов простоя и полумиллиона рублей. Мы собрали 3 узла Dell PowerEdge R750xa (Xeon Platinum 8280, 256 ГБ RAM, 4 × 2 ТБ NVMe RAID-10, 40G Mellanox), поставили в дата-центр МТС в Москве в одной стойке с клиентским приложением. InnoDB Cluster single-primary, MySQL Router на 4 фронтах. Время failover по наблюдениям — 8–14 секунд. За 6 месяцев с момента запуска — 2 автоматических failover при плановых обновлениях, 0 ручных вмешательств, ноль простоев. База — 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, slow queries. Алерты — на любой сбой кворума, на рост lag на 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 и даёт горячий бэкап без блокировок.