MySQL-Cluster und Replikation
(Abschnitt: Technologie und Infrastruktur)
Kurze Zusammenfassung
MySQL bleibt eine der Hauptkonturen des „Wahrheitssystems“ für Geld, KYC und Backoffice-Daten. Für iGaming-Lasten benötigen Sie: strikte Konsistenz von Geldtransaktionen, hohe Verfügbarkeit, kontrollierte Verzögerung und einen klaren DR-Plan. Basis-Stack: MySQL 8 + InnoDB, ROW-binlog + GTID, Semi-Sync auf kritischen Pfaden, Group Replication/InnoDB Cluster für HA, ProxySQL/MySQL Router für Routing, regelmäßige Backups + PITAS R..
Architektonische Muster
1) Primary-Replica (klassisch)
Primary akzeptiert Einträge; replica lesen und versichern DR.
Replikation: ROW-Format binlog, GTID enthalten.
Für Geldbildschirme - Lesen von primary oder streng kontrolliertes Lesen-nach-Schreiben.
2) Semi-sync над Primary–Replica
Der primäre Commit wartet auf mindestens einen Eintrag pro Replikat → RPO≈0 -1 Ereignis bei Ausfall.
Der Preis ist eine kleine Erhöhung der Latenz pro Aufnahme.
3) MySQL Group Replication (GR) / InnoDB Cluster
Quorum-Clustering (Transaktionszertifizierung), Modi:- Single-Primary: ein Knoten schreibt, der Rest liest (empfohlen für Geld).
- Multi-Primary: Schreiben auf mehreren - nur für konfliktarme Domains.
- MySQL Router verteilt Verbindungen; ClusterSet ist ein multiregionaler DR.
4) Sharding/polyglott
Wir skalieren den Geldkern vertikal und für Stories/Logs - Take-away in OLAP/NoSQL.