Geschrieben wird in die Primär-DB, gelesen aus dem Replikat. Hinkt das Replikat hinterher, ist gerade Geschriebenes dort noch nicht zu sehen.
Warum Schreiblast häuft sich auf der Primär-DB, das Replikat liegt einige Sekunden zurück → Folge Gerade Gespeichertes fehlt beim Lesen aus dem Replikat noch → Auf dem Bildschirm Gerade gekauftes Item nicht sichtbar, veraltete Preise auf dem Marktplatz, Bugs durch doppelte Vergabe
Gerade geschriebene Daten aus der Primär-DB lesen, Prüfung und Vergabe in einer einzigen Transaktion auf der Primär-DB ausführen (Duplikate per Unique Key oder bedingtem UPDATE verhindern).
Aufgaben Infrastrukturteam
Alarm auf Replikationsverzögerung einrichten, Replikate mindestens so groß wie die Primär-DB dimensionieren und parallele Replikation einsetzen, Massenlöschungen in kleinen Portionen ausführen, lang laufende Aggregations-Queries auf Replikaten im Griff behalten.
Im Graphen
Steigt mit Spielerzahl und Last · Replikationsverzögerung (s)
Wo nachsehen
MySQL: auf dem Replikat Seconds_Behind_Source aus SHOW REPLICA STATUS prüfen (vor Version 8.0.22 SHOW SLAVE STATUS). PostgreSQL: write_lag, flush_lag und replay_lag in pg_stat_replication auf dem Primärserver prüfen, bei RDS ReplicaLag
Spricht dafür
Zum Zeitpunkt der Meldung „nicht sichtbar“ liegt die Verzögerung bei mindestens einigen Sekunden, nach dem Aufholen ist alles wieder normal. Die Verzögerung wächst bei Schreibspitzen, Massenlöschungen oder langen Aggregations-Queries auf dem Replikat
Spricht dagegen
Verzögerung nahe 0, trotzdem nicht sichtbar: eher Cache oder Synchronisation im Spielserver
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Mehr dazu
Auch ohne viele Schreibvorgänge kann ein Replikat zurückfallen. Eine Massenlöschung, die auf der Primär-DB 10 Minuten dauerte, wird auf dem Replikat erneut ausgeführt und lässt es um ebenso viel zurückfallen. Lang laufende Aggregations-Queries auf dem Replikat bremsen das Aufholen ebenfalls.
Quellen
SHOW REPLICA STATUS StatementMySQL Seconds_Behind_Source: Abstand zu dem Zeitpunkt, zu dem das gerade vom Replikat angewendete Event auf der Primär-DB protokolliert wurde (Replikationsverzögerung)
Replica Server Options and VariablesMySQL Mit replica_parallel_workers wenden mehrere Threads Transaktionen parallel an (Standard 4, bei 0 ein einzelner Thread der Reihe nach)
Log-Shipping Standby Servers (PostgreSQL Documentation)PostgreSQL Streaming-Replikation ist standardmäßig asynchron, zwischen Commit und Übernahme ins Replikat liegt also eine Verzögerung (meist unter 1 s, wenn das Replikat mithalten kann)
The Cumulative Statistics System (PostgreSQL Documentation)PostgreSQL write_lag, flush_lag und replay_lag in pg_stat_replication: Zeit vom Schreiben des WAL auf dem Primärserver, bis das Replikat meldet, es geschrieben, auf den Datenträger übertragen bzw. angewendet zu haben