Fällt die Primär-DB aus und wird auf die Reserve-DB umgeschaltet, sind währenddessen keine Schreibvorgänge möglich, und die letzten noch nicht replizierten Daten können verloren gehen.
Warum Primär-DB fällt aus, die Reserve-DB wird zur Primär-DB hochgestuft → Folge Während der Umschaltung einige Sekunden bis einige Minuten keine Schreibvorgänge möglich, bei asynchroner Replikation droht Verlust nicht replizierter Daten → Auf dem Bildschirm Kurzzeitig schlägt jedes Speichern fehl, Rollback von Items und Erfahrungspunkten
Speichern wiederholbar gestalten, abgerissene Verbindungen schnell verwerfen und zur neuen Adresse neu aufbauen lassen (Einstellungen von Connection-Pool und DNS-Cache), bei Failover-Übungen den Reconnect prüfen.
Aufgaben Infrastrukturteam
Synchrone oder semisynchrone Replikation einsetzen (kostet Schreiblatenz), Failover regelmäßig üben, Failover-Dauer und Replikationsverzögerung überwachen.
Größenordnungen
Das automatische Failover verwalteter Datenbanken dauert meist einige Dutzend Sekunden bis 2 Minuten. Bei asynchroner Replikation können die jüngsten Speicherstände im Umfang der Replikationsverzögerung (unter 1 s bis einige Sekunden) verloren gehen.
Im Graphen
Verbindungen brechen gleichzeitig ab · DB-Verbindungen, Schreibfehler
Wo nachsehen
Failover-Protokoll der DB (bei RDS die Events RDS-EVENT-0013 Failover gestartet und RDS-EVENT-0049 Failover abgeschlossen, bei selbst betriebenen DBs das Promotion-Log) zusammen mit DB-Verbindungen und Verbindungsfehlern der Spielserver in einen Graphen legen. Bei asynchroner Replikation auch die Replikationsverzögerung direkt vor dem Ausfall prüfen (RDS ReplicaLag, replay_lag in PostgreSQL pg_stat_replication)
Spricht dafür
Fehlgeschlagenes Speichern ballt sich in einem Zeitraum zwischen Beginn und Ende des Failovers. Der zurückgesetzte Umfang entspricht etwa der Replikationsverzögerung direkt vor dem Ausfall. Spielserver, bei denen die Fehler nach Abschluss des Failovers weitergehen, nutzen noch Verbindungen zur alten Adresse
Spricht dagegen
Verbindungsabbrüche zu Zeiten ohne Failover-Eintrag: eher Netzwerk oder überlastete DB
Failing over a Multi-AZ DB instance for Amazon RDSAWS Multi-AZ-Failover dauert meist 60–120 s, danach müssen Verbindungen neu aufgebaut werden; empfohlen wird eine DNS-Cache-TTL der JVM von höchstens 60 s
High availability for Amazon AuroraAWS Während des Ausfalls schlagen Lese- und Schreibzugriffe fehl, die Wiederherstellung erfolgt meist innerhalb von 60 s (oft innerhalb von 30 s)
Semisynchronous ReplicationMySQL Bei asynchroner Replikation können committete Transaktionen auf dem Replikat fehlen, wenn die Primär-DB ausfällt; semisynchrone Replikation wartet auf die Empfangsbestätigung eines Replikats und verringert so das Risiko, erhöht aber die Latenz
Log-Shipping Standby Servers (PostgreSQL Documentation)PostgreSQL Log-Shipping ist asynchron, beim Ausfall des Primärservers gehen noch nicht übertragene Transaktionen verloren; die Verzögerung der Streaming-Replikation liegt meist unter 1 s