MySQL-кластеры и репликация

(Раздел: Технологии и Инфраструктура)

Краткое резюме

MySQL остается одним из основных контуров «системы правды» для денег, KYC и бэкофисных данных. Для iGaming-нагрузок нужны: строгая согласованность денежных транзакций, высокая доступность, контролируемый lag и понятный DR-план. Базовый стек: MySQL 8 + InnoDB, ROW-binlog + GTID, semi-sync на критичных путях, Group Replication / InnoDB Cluster для HA, ProxySQL/MySQL Router для маршрутизации, регулярные бэкапы + PITR.

Архитектурные паттерны

1) Primary–Replica (классика)

Primary принимает записи; replica читают и страхуют DR.
Репликация: ROW-формат binlog, GTID включен.
Для денежных экранов — чтение с primary или строго контролируемый read-after-write.

2) Semi-sync над Primary–Replica

Первичный коммит ждет хотя бы одну запись на реплику → RPO≈0–1 событие при отказе.
Цена — небольшая прибавка латентности на запись.

3) MySQL Group Replication (GR) / InnoDB Cluster

• Single-Primary: один узел пишет, остальные — читают (рекомендовано для денег).
• Multi-Primary: запись на нескольких — только для низкоконфликтных доменов.
• MySQL Router раздает подключения; ClusterSet — мульти-региональный DR.

4) Шардинг/полиглот

Вертикально масштабируем ядро денег, а для историй/логов — вынос в OLAP/NoSQL.