MySQL clusters and replication

(Section: Technology and Infrastructure)

Brief summary

MySQL remains one of the main outlines of the "truth system" for money, KYC and backoffice data. For iGaming workloads, you need: strict consistency of monetary transactions, high availability, controlled lag and an understandable DR plan. Basic stack: MySQL 8 + InnoDB, ROW-binlog + GTID, semi-sync on critical paths, Group Replication/InnoDB Cluster for HA, ProxySQL/MySQL Router for routing, regular backups + PITT R.

Architectural patterns

1) Primary-Replica (classic)

Primary accepts recordings; replica read and insure DR.
Replication: ROW binlog format, GTID enabled.
For money screens - reading from primary or strictly controlled read-after-write.

2) Semi-sync над Primary–Replica

The primary commit waits for at least one entry per replica → RPO≈0 -1 failure event.
The price is a small increase in latency per record.

3) MySQL Group Replication (GR) / InnoDB Cluster

• Single-Primary: one node writes, the rest read (recommended for money).
• Multi-Primary: write on multiple - for low-conflict domains only.
• MySQL Router distributes connections; ClusterSet is a multi-regional DR.

4) Sharding/polyglot

Vertically scale the core of money, and for stories/logs - take out in OLAP/NoSQL.