Jepsens Bewertung von MySQL 8.0.34

 (jepsen.io)
3 Punkte von GN⁺ 2023-12-20 | 1 Kommentare | Auf WhatsApp teilen

Hintergrund zu MySQL

  • MySQL ist seit 28 Jahren eine der am weitesten verbreiteten SQL-Datenbanken.
  • Es wird vor allem für Online Transaction Processing (OLTP) eingesetzt, aber auch für OLAP und als Teil von Queueing-Systemen bereitgestellt.
  • Es wurde als Single-Server-Datenbank konzipiert, aber durch verschiedene Multi-Node-Replikationsverfahren erweitert.
  • Die Analyse konzentriert sich auf MySQL mit der InnoDB-Storage-Engine.

ANSI-SQL-Isolationsstufen sind tatsächlich schlecht

  • Um die Feinheiten der SQL-Isolationsstufen zu diskutieren, ist eine Erklärung des historischen Hintergrunds der 1977 vorgeschlagenen vier Sicherheitsstufen für Transaktionskonsistenz und des 1986 von ANSI veröffentlichten SQL-Standards erforderlich.
  • ANSI SQL definiert Isolationsstufen über drei mögliche Phänomene (Dirty Reads, Non-Repeatable Reads und Phantoms).
  • 1995 wurden Mängel der ANSI-SQL-Isolationsstufen aufgezeigt, und 1999 entwickelte Adya eine formale und implementierungsunabhängige Definition der ANSI-SQL-Isolationsstufen.

MySQLs Isolationsstufen

  • Die MySQL-Dokumentation sagt, dass vier Transaktionsisolationsstufen angeboten werden, wie sie im Standard SQL:1992 beschrieben sind.
  • Sie enthält Erklärungen dazu, wie MySQL diese auf jeder Isolationsstufe erreicht.
  • Die Isolationsstufe Repeatable Read von MySQL soll Sicherheit über einen Snapshot-Mechanismus gewährleisten.

Testdesign

  • Mit der Jepsen-Testbibliothek wurde eine Testsuite für MySQL entworfen.
  • Die Tests wurden in verschiedenen Umgebungen durchgeführt, darunter ein einzelner MySQL-Knoten, ein binlog-Replikationscluster und ein AWS-RDS-Cluster.
  • Mit Elles list-append-Checker wurden zentrale Workloads zur Transaktionsisolation ausgeführt.

Ergebnisse

  • MySQLs Repeatable Read erlaubt G2-item, das in Adyas Isolationsstufe PL-2.99 verboten ist.
  • MySQLs Repeatable Read erlaubt außerdem G-single (Read Skew).
  • MySQLs Repeatable Read erlaubt das P4-Phänomen (Lost Update).
  • MySQLs Repeatable Read zeigt interne Konsistenzfehler.
  • MySQLs Repeatable Read verletzt Monotonic Atomic View.

GN⁺-Meinung

  • Dass sich MySQLs Isolationsstufe Repeatable Read anders verhält als im Standard beschrieben, ist eine wichtige Information für Entwickler und Datenbankadministratoren. Das bedeutet, dass Erwartungen an Datenkonsistenz und Isolation möglicherweise nicht erfüllt werden.
  • Die Testergebnisse liefern essenzielle Informationen, um die Isolationsstufen von Datenbanksystemen zu verstehen und geeignete Isolationsmechanismen auszuwählen.
  • Diese Erkenntnisse geben Einblick darin, wie sich Standards für Datenbank-Isolationsstufen von realen Implementierungen unterscheiden können. Das hilft dabei, die Komplexität von Datenbanktechnologien und die feinen Unterschiede zwischen Isolationsstufen besser zu verstehen.

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2023-12-20
Hacker-News-Kommentare

  • Ich vertrete schon lange die Ansicht, dass „repeatable read“ eine schlechte Idee ist. Selbst wenn die Implementierung perfekt ist und in der Datenbank korrekt funktioniert, ist es bei komplexen Abfragen schwer zu verstehen.

    • Ich denke, nur zwei Isolationsstufen sind sinnvoll:
      • read committed
      • serializable
    • Bei serializable gibt es nichts Unerwartetes. Bei read committed ist klar, dass man Zeilen sperren muss, bevor man anfängt, sie zu lesen, wenn man eine konsistente Sicht auf die Daten haben will.
    • read committed ist allgemeinem Multithread-Code und Speicherverwaltung sehr ähnlich, sodass die meisten Engineer es intuitiv verstehen können.
    • serializable ist sehr strikt, sodass man nur schwer unerwartete Fehler machen kann.
    • Die mittlere Stufe ist Niemandsland, und alles, was weniger konsistent ist als Read Committed, ist keine Datenbank mehr.

  • Auf der FOSSDEM-2024 ist ein Vortrag mit dem Titel „Isolation Levels and MVCC in SQL Databases: A Technical Comparative Study“ geplant.

    • Vergleichsstudie zu Oracle, MySQL, SQL Server, PostgreSQL und YugabyteDB.

  • Der Artikel bewertet AWS RDS, aber ich frage mich, ob es einen Fokus auf AWS Aurora (MySQL) gibt. AWS baut eine Datenbankplattform, die vorgibt, MySQL oder PostgreSQL zu sein. Es wäre interessant zu sehen, ob Aurora MySQL dieselben „Features“ wie RDS oder MariaDB hat.

  • Ich halte das für ein großartiges Beispiel für „tatsächlich funktionierende Systeme“, die auf einer Grundlage aufgebaut sind, die viele Konsistenzartefakte zeigt.

  • Es ist etwas beunruhigend, dass die RDS-Replikation nach 5 Minuten aufhört zu funktionieren und es keine Benachrichtigung über fehlgeschlagene Health Checks gibt.

  • Ich frage mich, wie append (a) in der gegebenen Tabelle auf tatsächliche SQL-Operationen abgebildet wird und ob ein TEXT-Feld als Liste verwendet wird.

    • Im repeatable-read-Modus von MySQL gab es ein Problem, bei dem ein einzelnes SELECT eine einzelne Zeile auswählte und ein unmögliches Ergebnis zurückgab. Zum Beispiel habe ich bei SELECT min(value), max(value) FROM table WHERE id = 1; schon unterschiedliche Werte für min und max erhalten, obwohl id der Primärschlüssel ist.

  • Hilfreich wäre ein Vergleich nicht nur mit den theoretischen Definitionen der Isolationsmodi, sondern auch mit anderen populären relationalen Datenbanken wie PostgreSQL, MS SQL und Oracle. Das sollten Entwickler im Hinterkopf behalten, wenn sie Kompatibilität sicherstellen wollen.

  • Es scheint, als sei „SELECT ... FOR UPDATE“ die Antwort auf all diese Probleme: Wenn man die zu aktualisierenden Zeilen sperrt, funktioniert alles wie beworben.

  • Ich wollte heute eigentlich etwas arbeiten, aber ich bin dankbar dafür, dass aphyrs „call me maybe“ und jepsen.io zu den besten Inhalten gehören, die ich je im Internet gelesen habe.

  • Ich frage mich, wie viel der MySQL-Analyse genauso für MariaDB gilt, das InnoDB als Standard-Storage-Engine verwendet.