Analyse von Amazon RDS PostgreSQL 17.4 – Snapshot Isolation wird nicht gewährleistet

• Multi-AZ-Cluster von Amazon RDS for PostgreSQL unterstützen laut offizieller Aussage Snapshot Isolation, verletzen diese in der Praxis jedoch häufig durch G-nonadjacent-Zyklen und das Long-Fork-Phänomen
• Die Tests basierten auf einer selbst aufgebauten PostgreSQL-Transaktions-Workload; von PostgreSQL 13.15 bis 17.4 traten in allen Versionen Konsistenzfehler auf
• Diese Fehler treten hauptsächlich auf schreibgeschützten sekundären Knoten auf, und selbst auf dem Niveau "Repeatable Read" wird Snapshot Isolation verletzt
• RDS-Cluster könnten Konsistenz auf dem Niveau von Parallel Snapshot Isolation bieten, was ein schwächeres Modell als bei einem einzelnen PostgreSQL-Standardknoten ist
• Schreibgeschützte Transaktionen können unterschiedliche Transaktionsreihenfolgen beobachten; solche Inkonsistenzen können zu Fehlern bei der Datenintegrität führen

---

Hintergrund

• PostgreSQL ist eine Open-Source-SQL-Datenbank auf MVCC-Basis und bietet verschiedene Transaktionsisolationsstufen. Repeatable Read entspricht dabei tatsächlich Snapshot Isolation
• Amazon RDS bietet PostgreSQL als gemanagten Cluster an; die Multi-AZ-Konfiguration ist eine Architektur für Replikation und Fehlertoleranz
• Der primäre Endpoint erlaubt Lesen und Schreiben, sekundäre Knoten sind schreibgeschützt und unterstützen das Serializable-Niveau nicht

Testdesign

• Das Jepsen-Testwerkzeug für PostgreSQL wurde für RDS angepasst, um automatisierte Transaktionstests durchzuführen
• Die Transaktionen wurden so entworfen, dass sie Listen bestimmter Schlüssel lesen oder eindeutige Ganzzahlen anhängen; der Elle-Checker erkannte dabei Zyklen
• Bei einer Last von 150 TPS Schreiben und 1600 TPS Lesen wurden Long Fork und G-nonadjacent innerhalb von 2 Minuten bestätigt

Ergebnisse

• Ein G-nonadjacent-Zyklus aus 4 Transaktionen belegt die Verletzung von Snapshot Isolation
  • T₂ beobachtete die Änderungen von T₁, sah aber T₃ nicht; T₄ sah T₃, aber nicht T₁ → ein gegenseitiger Widerspruch in der zeitlichen Reihenfolge entsteht
• Dies ist ein Fall des Long-Fork-Phänomens und
• Da kein Write Skew gefunden wurde, stützt dies die Möglichkeit von Parallel Snapshot Isolation

Diskussion

• Multi-AZ-RDS bietet ein niedrigeres Konsistenzniveau als ein einzelner PostgreSQL-Knoten
• Da bei der Nutzung schreibgeschützter Knoten Konsistenzfehler möglich sind, sollte erwogen werden, ausschließlich den Schreibknoten zu verwenden oder in jede Transaktion mindestens einen Schreibvorgang einzubauen
• Diese Analyse befindet sich noch auf dem Niveau früher Tests; sie beweist das Vorhandensein des Problems, garantiert aber nicht seine Abwesenheit

[GN⁺]

Hacker-News-Kommentare

• Im Artikeltitel wird es nicht klar erwähnt, aber es geht um das neue RDS-Feature Multi-AZ Cluster

  • Multi-AZ-Instanzen sind das ältere Feature, bei dem die primäre DB synchron auf eine Standby-DB in einer anderen AZ repliziert wird
  • Multi-AZ-Cluster haben zwei Standby-DBs, und Transaktionen werden synchron auf mindestens eine Standby-DB repliziert
  • Das ist robuster, falls eine Standby-DB ausfällt oder langsamer wird, und erlaubt schreibgeschützten Zugriff auf die Standby-DBs
  • Multi-AZ-Cluster sind kein allgemeines Postgres-Feature, was ein Grund sein könnte, warum sie im Jepsen-Test durchfallen

• In einem früheren Unternehmen traten beim Wiederherstellen von Backups Konsistenzprobleme auf (Duplicate-Key-Fehler und FK-Constraint-Fehler), als der pg_dump-Befehl im Backup-Skript auf parallele Worker (-j-Flag) umgestellt wurde

  • Wir haben das Problem an die AWS- und Postgres-Mailinglisten gemeldet, aber es ließ sich nicht leicht reproduzieren und wurde deshalb nicht gelöst
  • Am Ende sind wir wieder zu Single-Thread-Dumps zurückgekehrt, und ich frage mich, ob dieses Problem mit dem Verhalten zusammenhängt, das wir damals beobachtet haben

• Jepsen hat diese Arbeit unabhängig durchgeführt und wurde nicht dafür bezahlt

  • Das ist keine Nachricht, die RDBMS-Interessengruppen an einem guten Tag hören wollen
  • Respekt an aphyr

• Die praktische Bedeutung dieses Problems ist, dass Lesezugriffe, die kurz nach einem Schreibzugriff auf dieselbe Zeile erfolgen, veraltete Daten zurückgeben können

  • Bevor eine Schreibtransaktion als abgeschlossen markiert wird, sind nicht alle verteilten Schichten einer Multi-AZ-RDS-Instanz vollständig aktualisiert, sodass unmittelbare Lesezugriffe nicht vorhandene Zeilen oder veraltete Werte zurückgeben können
  • Aufgrund der Snapshot-Mechanik von PostgreSQL werden nicht nur einige Bytes eines mehrbyteigen Spaltentyps aktualisiert, sodass ein Lesezugriff unsinnige Werte erhält
  • Es wirkt letztlich wie eine Race-Condition, die irgendwann konsistent wird

• Es ist nicht klar, ob es in vorgelagerten Postgres-Clustern mit mehreren Instanzen dieses Problem nicht gibt

  • Ich frage mich, ob AWS der Cluster-Konfiguration etwas hinzugefügt oder einen Patch eingebaut hat, der dieses Verhalten verursacht

• Der eingereichte Titel verschleiert den Kernpunkt: RDS für PostgreSQL 17.4 implementiert Snapshot Isolation nicht korrekt

• Ich frage mich, welche Sicherheits- oder Anwendungsfehler auf Anwendungsebene auftreten könnten, wenn Entwickler Snapshot Isolation voraussetzen, Amazon RDS for PostgreSQL aber tatsächlich nur Parallel Snapshot Isolation bietet, insbesondere in Multi-AZ-Konfigurationen mit Read-Replica-Endpunkten

• Dieses Verhalten trat in allen getesteten Versionen von 13.15 bis 17.4 auf

  • Ich hatte Sorge, dass das Upgrade der Hauptversion die falsche Entscheidung gewesen sein könnte, aber es ist keine Regression, sondern eher ein Feature-Request oder ein langjähriger Bug

• Es wäre gut, alle Versionen von Amazon RDS mit Jepsen zu testen

• AWS sollte die Dokumentation aktualisieren, um darauf hinzuweisen

  • Ich frage mich, ob eine Korrektur der Snapshot Isolation bei Latenz oder Durchsatz zu Performance-Regressionen führen würde, oder ob man argumentieren wird, dass der aktuelle Zustand stark genug ist
  • In jedem Fall sollte AWS das erwähnen