Ein Fall zur Entdeckung einer Race Condition in Aurora RDS

• Ein Fall, in dem ein Race-Condition-Bug in AWS Aurora RDS experimentell bestätigt und die Ursache von AWS verifiziert wurde
• Hightouch entdeckte während der Skalierung seines Event-Verarbeitungssystems, dass beim Failover von Aurora die Umschaltung der Writer-Instanz fehlschlug
• Die Log-Analyse zeigte, dass zwei Instanzen gleichzeitig Schreibvorgänge ausführten, was zu Konflikten in der Storage-Schicht und zum Abbruch von Prozessen führte
• AWS bestätigte offiziell, dass aufgrund eines Problems bei der internen Signalverarbeitung der neue Writer befördert wurde, bevor die Degradierung des vorherigen Writers abgeschlossen war
• Der Fall unterstreicht die Bedeutung der Nebenläufigkeitskontrolle in großen verteilten Systemen sowie die Notwendigkeit, Schreibvorgänge während eines Failovers zu unterbrechen

---

Hintergrund

• Am 20. Oktober 2025 kam es in der AWS-Region us-east-1 zu einem Ausfall durch einen Race-Condition-Bug im DNS-Verwaltungssystem
• Bei Hightouch wuchs dadurch der Backlog der Event-Verarbeitung sprunghaft an und brachte das System an seine Grenzen
• Um mehr Durchsatz zu gewinnen, führte das Unternehmen am 23. Oktober ein Upgrade der Aurora-RDS-Instanzen durch und entdeckte dabei einen weiteren Race-Condition-Bug

Architektur des Hightouch-Event-Systems

• Das System für Erfassung und Versand von Events besteht aus Kubernetes, Kafka und Postgres (Aurora)
• Postgres wird als Queue für Batch-Metadaten verwendet und verarbeitet 500.000 Events pro Sekunde innerhalb von 1 Sekunde
• Aurora PostgreSQL besteht aus einer schreibenden (primary) Instanz, einer nur lesenden (replica) Instanz sowie einer gemeinsam genutzten Storage-Schicht

Upgrade-Plan

• Hinzufügen einer Leseinstanz → Upgrade des bestehenden Readers und Vergabe der Failover-Priorität → Ausführen des Failovers → Upgrade des bisherigen Writers → Entfernen des temporären Readers
• Dieses Verfahren ist in der AWS-Dokumentation beschrieben und wurde in einer Staging-Umgebung per Lasttest validiert

Upgrade-Versuch und Auftreten des Problems

• Am 23. Oktober um 16:39 EDT trat nach dem Ausführen des Failovers das Phänomen auf, dass der bisherige Writer wieder als Primary zurückkehrte
• Bei beiden Versuchen trat dasselbe Ergebnis auf, und in einigen Services kam es zu Schreibfehlern (DatabaseError: cannot execute UPDATE in a read-only transaction)
• Die Log-Analyse zeigte Einträge, aus denen hervorging, dass zwei Instanzen gleichzeitig Schreibvorgänge ausführten und sich dann wegen Storage-Konflikten beendeten

Ursache der Race Condition

• Während des Failover-Prozesses von Aurora trat zwischen Schritt 3 (Degradierung des bisherigen Writers) und Schritt 4 (Beförderung des neuen Writers) eine Race Condition auf
• Dadurch besaßen zwei Instanzen gleichzeitig Schreibrechte und gerieten in Konflikt
• Nachdem der Schreibverkehr entfernt worden war, wurde der Failover erneut versucht und erfolgreich abgeschlossen, womit die Hypothese einer Race Condition bestätigt wurde

Bestätigung und Reaktion von AWS

• Nach interner Prüfung bestätigte AWS, dass ein Fehler bei der Verarbeitung des Signals zur Writer-Degradierung die Ursache war und nicht die Konfiguration oder das Traffic-Muster von Hightouch
• Ein Fix ist in der Roadmap enthalten, und als vorläufige Maßnahme empfiehlt AWS, Schreibvorgänge während des Failovers zu unterbrechen

Abschließende Maßnahmen

• Hightouch schloss das Cluster-Upgrade ab und setzte anschließend Folgendes um:
  • Einführung eines Verfahrens zum Unterbrechen von Schreibvorgängen vor absichtlichem Failover
  • Verstärkte Überwachung von Änderungen der Writer-Rolle
  • Aktualisierung des Betriebs-Playbooks

Zentrale Lehren

1. Für unerwartete Zustandswechsel während Migrationen muss eine Wiederherstellungsstrategie vorbereitet sein
2. Observability ist entscheidend für die Problemerkennung
3. Die Minimierung von Wechselwirkungen zwischen Komponenten verteilter Systeme ist ein wichtiger Designaspekt
4. Die Unterschiede zwischen Testumgebung und realer Produktionsumgebung müssen berücksichtigt werden

Keine weiteren Informationen im Originaltext

[GN⁺]

Hacker-News-Kommentare

• Beim Lesen wirkt es so, als würde es während eines manuellen Failovers immer scheitern, wenn die Anwendung versucht, den Schreibverkehr wie gewohnt aufrechtzuerhalten
  Trotzdem wirft das einige Fragen auf. Warum erleben andere Aurora-Nutzer dieses Problem nicht ständig, wie könnte AWS davon nichts wissen, und falls doch, warum wird es nicht als P0-Notfallproblem behandelt?
  Ich frage mich, ob dabei subtile Bedingungen wie der Zustand laufender Transaktionen oder Timeouts eine Rolle spielen

  • Aus meiner Erfahrung mit ähnlichen Problemen bei Azure: Viele Leute erleben so etwas, aber weil es sich durch einen Neustart beheben lässt, wird es einfach hingenommen. Die eigentliche Ursache zu finden ist schwierig, und die Analyse zusammen mit dem Vendor ist so schmerzhaft, dass die meisten aufgeben
  • Wir haben dasselbe Problem ebenfalls in Zusammenarbeit mit AWS bestätigt. Das Traffic-Muster war nicht ungewöhnlich, und in anderen Regionen ließ es sich nicht reproduzieren. Das deutet stark auf einen grundlegenden Fehler im Failover-Mechanismus von Aurora hin
  • Ich hatte früher bei der Kombination aus Python + MySQL einen Bug, bei dem SELECT ... FOR UPDATE stillschweigend fehlschlug und die Transaktion in den Autocommit-Modus wechselte. Niemanden hat es interessiert, also habe ich allein darüber geredet, und Monate später meldete sich jemand, der dasselbe Problem hatte. Es wurde am Ende zwar behoben, aber da hatte ich das Interesse schon verloren
    Zugehöriger Link: Stack Overflow-Frage
  • AWS gibt intern fast nichts preis. Über die API-Ebene hinaus werden keine Details mitgeteilt, daher hat man das Gefühl, dass solche Probleme einfach als seltene Sonderfälle abgetan werden
  • Ein Teil des Problems könnte auch daran liegen, wie die Anwendung auf ein zurückgerolltes Failover reagiert. Offenbar wurde ein Cache ungültig und es wurde weiter an eine falsche Primary geschrieben. Selbst wenn solche Fehler gelegentlich auftreten, führen Retries oft zum Erfolg, sodass Nutzer sie womöglich nicht an AWS melden und AWS deshalb keine Kenntnis davon hat

• Ich habe bei Aurora PostgreSQL mehrfach unerwartetes Verhalten gesehen
  Besonders während Zero Downtime Patching (ZDP) wurde der Sitzungszustand offenbar falsch beibehalten, sodass selbst einfache Queries deutlich früher als statement_timeout abgebrochen wurden
  Meine Vermutung ist, dass Aurora beim Reconnect des Clients den veralteten Timer-Zustand der vorherigen Sitzung übernimmt, wodurch Queries sofort abgebrochen werden

• Wir führen in einer Umgebung mit sehr hohem Schreibaufkommen ebenfalls regelmäßig Failovers durch, betreiben das aber mithilfe des AWS JDBC wrapper in einem automatisierten Prozess stabil

  • Tatsächlich hat in der Praxis die Storage-Schicht von Aurora ACID-Verstöße verhindert, das heißt, die Datenintegrität blieb gewahrt

• Man bezahlt doch gerade dafür, dass Aurora solche grundlegenden Invarianten einhält, daher ist es überraschend, dass so etwas passiert

  • Die Storage-Schicht selbst hat jedoch gleichzeitige Schreibzugriffe blockiert und damit korrekt funktioniert

• Wenn man die Logs und die Erklärung von AWS betrachtet, scheint die Hypothese des Autors des Originalposts falsch zu sein
  Nach einem fehlgeschlagenen Promotion-Vorgang hat offenbar ein externer Überwachungsprozess eine Inkonsistenz im Cluster-Zustand erkannt und per kill -9 beendet. Meldungen zum Storage-Subsystem traten erst danach auf

• Ich würde gern nach dem Leistungsvergleich zwischen Aurora und RDS Postgres fragen.
  Wenn Multi-AZ oder schnelles Failover nicht nötig sind, lässt sich mit einer gp3-64k-IOPS-Konfiguration auf RDS bessere Performance erzielen? Aurora wirkt vor allem bei Insert-Performance langsam und teuer. Benchmarks sind schwer vertrauenswürdig, weil die RDS-Konfiguration oft nicht klar angegeben wird

  • Wir haben mit Aurora PG 14 in einer 1-Writer- plus 1~2-Reader-Konfiguration bessere Performance und niedrigere Kosten erzielt. Aurora ist vorteilhaft, weil der Storage nicht pro Instanz, sondern auf Cluster-Ebene abgerechnet wird.
    Außerdem muss man IOPS nicht direkt provisionieren und erhält ungefähr 80k IOPS.
    Es gibt auch zwei IO-Abrechnungsmodelle: Pay-per-IO ist für Umgebungen mit geringer Last geeignet, während der Pauschalmodus bei IO-intensiven Workloads im Vorteil ist.
    Serverless war übrigens fast immer unwirtschaftlich. Nützlich ist es nur bei kurzen Lastspitzen
  • Unser Team hatte bei Aurora Postgres RDS einen explosionsartigen Anstieg der I/O-Kosten. Schon einige wenige Fuzzy-Queries führten zu monatlichen Kosten von über 3.000 US-Dollar, obwohl es eigentlich unter 100 US-Dollar hätte bleiben sollen
  • Bei Kosten, Performance und Latenz hat Aurora uns so enttäuscht, dass wir letztlich zu On-Premises-PostgreSQL migriert sind
  • Für Aurora MySQL galt: Wenn wir dieselben IOPS auf RDS erreichen wollten, wären die Kosten deutlich höher gewesen
  • Aurora verwendet kein EBS, und man kann weder Storage-Typ noch Latenz auswählen. Man kann lediglich das IO-Abrechnungsmodell wählen

• Hier zeigt sich gut das „Lego-Block-Modell“, von dem AWS-Ingenieure sprechen
  Die Storage-Schicht wurde vollständig unabhängig entworfen, sodass selbst beim Ausfall übergeordneter Services die Datenkonsistenz erhalten blieb. Ich halte das für ein gutes Beispiel für AWS-Engineering

• Es heißt, AWS habe empfohlen, während eines Failovers keine Schreibvorgänge auszuführen. Ich würde gern wissen, ob die zugehörige Fallnummer geteilt werden kann

  • Wir verwenden ebenfalls Aurora MySQL und möchten prüfen, ob diese Empfehlung auch für MySQL gilt

• Gut zu wissen, dass ich mit diesem Problem nicht allein bin

  • AWS Support widersprach zunächst und meinte, es liege an Replication Lag, stützte sich dabei aber auf veraltete Metriken von vor 24 Stunden. Ich würde wirklich gern verstehen, was für ein Fehler aufgetreten ist und warum er sich in anderen Regionen nicht reproduzieren ließ

• Die Architektur mit getrennter Compute- und Storage-Schicht von Aurora ist interessant
  Hyperscale bei MSSQL hat eine ähnliche Struktur und ist unter den Azure-Diensten fast das einzige Produkt, das ich tatsächlich nutzen würde