Klastry i replikacje MySQL
(Sekcja: Technologia i infrastruktura)
Krótkie podsumowanie
MySQL pozostaje jednym z głównych zarysów „systemu prawdy” dla pieniędzy, KYC i danych backoffice. W przypadku obciążenia pracą iGaming potrzebujesz: ścisłej spójności transakcji pieniężnych, wysokiej dostępności, kontrolowanego opóźnienia i zrozumiałego planu DR. Podstawowy stos: MySQL 8 + InnoDB, ROW-binlog + GTID, półsynchronizacja na ścieżkach krytycznych, Grupa replikacji/Klaster InnoDB dla HA, ProxySQL/MySQL Router dla routingu, regularne kopie zapasowe + PITT R..
Wzory architektoniczne
1) Podstawowa replika (klasyczna)
Podstawowy akceptuje nagrania; replika odczytać i ubezpieczyć DR.
Replikacja: format binlog ROW, włączony GTID.
Dla ekranów pieniężnych - odczyt z pierwotnego lub ściśle kontrolowanego odczytu po zapisie.
2) Półsynchronizacja niana- replika pierwotna
Podstawowy commit czeka na co najmniej jeden wpis na replikę → zdarzenie awaryjne RPO ≤ 0 -1.
Cena jest niewielkim wzrostem opóźnień na rekord.
3) Replikacja grupy MySQL (GR )/Klaster InnoDB
Klastrowanie kworum (certyfikacja transakcji), tryby:- Single-Primary: jeden węzeł pisze, reszta odczytuje (polecany za pieniądze).
- Multi-Primary: zapisz na wielu - tylko dla domen o niskim stopniu konfliktu.
- MySQL Router dystrybuuje połączenia; ClusterSet jest wieloregionalnym DR.
4) Shading/poliglot
Pionowo skalować rdzeń pieniędzy, a dla historii/dzienników - wyjąć w OLAP/NoSQL.