MySQL clústeres y replicación
(Sección: Tecnologías e Infraestructura)
Resumen breve
MySQL sigue siendo uno de los principales circuitos del «sistema de la verdad» para el dinero, KYC y datos de backofis. Para las cargas de iGaming se necesita: una estricta consistencia de las transacciones en efectivo, alta disponibilidad, un registro controlado y un plan de DR comprensible. Pila básica: MySQL 8 + InnoDB, ROW-binlog + GTID, semi-sync en rutas críticas, Group Replication/InnoDB Cluster para HA, ProxySQQ Enrutador L/MySQL para enrutamiento, backups regulares + PITR.
Patrones arquitectónicos
1) Primary-Replica (clásico)
Primary acepta registros; replica leer y asegurar DR.
Replicación: formato ROW binlog, GTID está habilitado.
Para las pantallas de dinero - leer con primary o estrictamente controlado read-after-write.
2) Semi-sync над Primary–Replica
El commit primario espera al menos un registro por réplica → RPO≈0 -1 evento si falla.
El precio es un pequeño aumento de latencia por registro.
3) MySQL Group Replication (GR) / InnoDB Cluster
Clustering de quórum (certificación de transacciones), modos:- Single-Primary: un nodo escribe, el resto lee (recomendado para dinero).
- Multi-Primary: grabar en varios - sólo para dominios de bajo conflicto.
- MySQL Router distribuye conexiones; ClusterSet - DR multi-regional.
4) Charding/políglota
Escalamos verticalmente el núcleo del dinero, y para historias/registros, llevamos a OLAP/NoSQL.