Clusters MySQL et réplication
(Section : Technologie et infrastructure)
Résumé succinct
MySQL reste l'un des principaux contours du « système de vérité » pour l'argent, le KYC et les données de bacoffice. Pour les charges iGaming, vous avez besoin d'une stricte cohérence des transactions monétaires, d'une haute disponibilité, d'un lag contrôlé et d'un plan DR clair. Pile de base : MySQL 8 + InnoDB, ROW-binlog + GTID, semi-sync sur les chemins critiques, Group Replication/InnoDB Cluster pour HA, ProxySQL/MySQL Router pour le routage, régulier backups + PITR.
Modèles architecturaux
1) Primary-Replica (classique)
Primary accepte les enregistrements ; replica est lu et assuré par DR.
Réplication : Format binlog ROW, GTID activé.
Pour les écrans monétaires - lecture avec primary ou strictement contrôlé read-after-write.
2) Semi-sync над Primary–Replica
Le commit principal attend au moins une entrée par réplique → RPO≈0 -1 événement en cas de panne.
Le prix est une petite augmentation de latence sur l'enregistrement.
3) MySQL Group Replication (GR) / InnoDB Cluster
Clustering de quorum (certification des transactions), modes :- Single-Primary : un nœud écrit, les autres lisent (recommandé pour l'argent).
- Multi-Primary : écriture sur plusieurs - uniquement pour les domaines à faible conflit.
- MySQL Router distribue les connexions ; ClusterSet est un DR multirégional.
4) Charding/polyglotte
Nous mettons à l'échelle verticalement le noyau de l'argent, et pour les histoires/logs - sortir dans OLAP/NoSQL.