Es gibt auch viele Einführungen in das MySQL-Transaktionsmodell im Internet. Bevor ich diesen Artikel schreibe, habe ich auch viele Informationen als Referenz gelesen, in der Hoffnung, mein Verständnis zu vertiefen. tiefgründig und umfassend. Nachdem ich die meisten Einführungsartikel gelesen hatte, stellte ich fest, dass einige davon unvollständig sind. Einige stellen beispielsweise nur die Leistung von MySQL unter mehreren Isolationsstufen vor und erklären sie nicht aus technischer Sicht. Einige Artikel sind sehr umfangreich, aber es mangelt ihnen an Organisation und sie sind nicht leicht zu verstehen. Dies ist auch die Hoffnung des Autors, Ihnen etwas anderes zu bieten, es aus technischer Sicht zu interpretieren und das Verständnis zu erleichtern.
MySQL-Transaktionsatomaritätsgarantie
Transaktionsatomizität erfordert, dass eine Reihe von Vorgängen in der Transaktion vollständig abgeschlossen sein müssen oder keine Operation ausgeführt werden muss und nicht ausgeführt werden kann zur Hälfte. Atomarität ist für atomare Operationen einfach zu implementieren, ebenso wie die Atomaritätsimplementierung von Transaktionen auf Zeilenebene in HBase relativ einfach ist. Wenn jedoch bei einer Transaktion, die aus mehreren Anweisungen besteht, während der Ausführung der Transaktion eine Ausnahme auftritt und die Atomizität sichergestellt werden muss, besteht die einzige Möglichkeit darin, auf den Zustand vor Beginn der Transaktion zurückzusetzen, als ob die Transaktion nie stattgefunden hätte alle. Wie erreicht man das?
MySQLs Implementierung des Rollback-Vorgangs basiert vollständig auf dem Rückgängig-Protokoll. Außerdem wird das Rückgängig-Protokoll in MySQL verwendet, um MVCC zusätzlich zur Erreichung der Atomizitätsgarantie zu implementieren, was ebenfalls weiter unten behandelt wird. Verwenden Sie Rückgängig, um Atomizität zu erreichen. Bevor Sie Daten bearbeiten, werden die Daten vor der Änderung zunächst im Rückgängig-Protokoll aufgezeichnet und dann die eigentliche Änderung vorgenommen. Wenn eine Ausnahme auftritt und ein Rollback erforderlich ist, kann das System die Sicherung beim Rückgängigmachen verwenden, um die Daten in den Zustand vor Beginn der Transaktion wiederherzustellen. Die folgende Abbildung zeigt die grundlegende Datenstruktur, die Transaktionen in MySQL darstellt. Die mit dem Rückgängigmachen verbundenen Felder sind insert_undo und update_undo, die jeweils auf das von dieser Transaktion generierte Rückgängig-Protokoll verweisen.
Transaktions-Rollback findet das entsprechende Rückgängig-Protokoll basierend auf update_undo (oder insert_undo) und führt den umgekehrten Vorgang aus. Bei Daten, die zum Löschen markiert wurden, bereinigen und löschen Sie die Markierung und setzen Sie die Aktualisierung für die aktualisierten Daten direkt zurück. Der Einfügevorgang ist etwas komplizierter. Es müssen nicht nur die Daten, sondern auch die zugehörigen Daten gelöscht werden Clustered-Index- und Sekundärindex-Datensätze.
Das Rückgängig-Protokoll ist ein sehr wichtiger Inhalt im MySQL-Kernel. Es erfordert viel Wissen und ist komplex, wie zum Beispiel:
1 Das Rückgängig-Protokoll muss vor den Daten gespeichert werden Wird geändert. Die Persistenz des Undo-Protokolls erfordert keine Notwendigkeit, Redo aufzuzeichnen, um Ausfallausnahmen zu verhindern. Bei Bedarf ist eine Wiederherstellung nach Ausfallzeit erforderlich ...
2. Wie implementiert man MVCC durch Rückgängigmachen?
3. In welchen Szenarien können diese Rückgängig-Protokolle recycelt und bereinigt werden? Wie reinige ich es?
MySQL-Transaktionskonsistenzgarantie: Starke Konsistenztransaktionsgarantie
MySQL-Transaktionsisolationsstufe
Read Uncommitted (RU Technische Interpretation: Verwendung Die Genauigkeit dieser geänderten Daten ist nicht zuverlässig (sie können zurückgesetzt werden), daher sind alle auf dieser Grundlage getroffenen Annahmen unzuverlässig. In realen Szenarien würden sich nur wenige Unternehmen für diese Isolationsstufe entscheiden.
Der Mechanismus zur Implementierung der Schreibparallelität unterscheidet sich nicht von dem von HBase. Beide werden mithilfe eines zweiphasigen Sperrprotokolls implementiert, um den entsprechenden Datensätzen Zeilensperren hinzuzufügen. Allerdings ist der Zeilensperrmechanismus in MySQL relativ komplex. Es gibt verschiedene Sperrsituationen, je nachdem, ob es sich bei dem Zeilendatensatz um einen Primärschlüsselindex, einen eindeutigen Index, einen nicht eindeutigen Index oder keinen Index handelt.
1. Wenn die ID-Spalte ein Primärschlüsselindex ist, sperrt MySQL nur Clustered-Index-Datensätze.
2. Wenn die ID-Spalte der einzige sekundäre Index ist, sperrt MySQL die sekundären Indexblattknoten und gruppierten Indexdatensätze.
3. Wenn es sich bei der ID-Spalte um einen nicht eindeutigen Index handelt, sperrt MySQL alle sekundären Indexblattknoten, die die Bedingung erfüllen (id = 15), und die entsprechenden Clustered-Index-Datensätze.
4. Wenn die ID-Spalte nicht indiziert ist, führt SQL einen vollständigen Tabellenscan mit Clustered-Index durch und lädt die Scanergebnisse zum Filtern in die SQL Server-Ebene Wenn der Filter die Bedingungen nicht erfüllt, gibt InnoDB die Sperre frei. Daher sperrt InnoDB alle gescannten Datensätze, was beängstigend ist!
Als Nächstes verwendet die Schreibparallelitätskontrolle den oben genannten Mechanismus, sodass ich nicht auf Details eingehen werde. Als Nächstes konzentrieren wir uns auf die Analyse der Mechanismen zur Steuerung der Lese- und Schreib-Parallelität in den Isolationsstufen RC und RR.
Bevor RC und RR im Detail vorgestellt werden, muss zunächst der MVCC-Mechanismus in MySQL eingeführt werden, da sowohl RC als auch RR den MVCC-Mechanismus verwenden, um Lese- und Schreibparallelität zwischen Transaktionen zu erreichen. Es gibt lediglich einige Unterschiede zwischen den beiden in den Implementierungsdetails. Die spezifischen Unterschiede werden als Nächstes besprochen.
MVCC in MySQL
Der MVCC-Mechanismus in MySQL ist viel komplexer als der von HBase, und auch die beteiligten Datenstrukturen sind komplexer. Um es anschaulicher zu erklären, wird eine Kastanie als Erklärungsvorlage verwendet. Beispielsweise gibt es derzeit eine Reihe von Datensätzen wie unten gezeigt:
Die ersten vier Spalten sind die tatsächlich in der Zeile aufgezeichneten Spaltenwerte. Worauf man sich konzentrieren muss, sind die beiden versteckten Spalten DB_TRX_ID und DB_ROLL_PTR (für den Benutzer unsichtbar). Unter diesen stellt DB_TRX_ID die Transaktions-ID der Transaktion dar, die die Zeile ändert, und DB_ROLL_PTR stellt den Zeiger auf das Rollback-Segment der Zeile dar. Alle in dieser Zeile aufgezeichneten Versionsdaten sind in Form einer verknüpften Liste in diesem Wert organisiert verweist tatsächlich auf den Verlauf der Zeile in der Rückgängig-Liste.
Angenommen, dass eine Transaktion trx2 die Datenzeile ändert, ändert sich der Zeilendatensatz wie folgt: DB_TRX_ID ist die Transaktions-ID (trx2) der Transaktion, die die Zeile zuletzt geändert hat, und DB_ROLL_PTR zeigt auf Verknüpfte Liste mit Verlaufsdatensätzen rückgängig machen:
Nachdem wir MySQL-Zeilendatensätze verstanden haben, werfen wir einen Blick auf die Grundstruktur von Transaktionen. Die folgende Abbildung zeigt die Transaktionsdatenstruktur von MySQL wir oben erwähnt. Nachdem die Transaktion gestartet wurde, wird eine Datenstruktur erstellt, um transaktionsbezogene Informationen, Sperrinformationen, das Rückgängig-Protokoll und sehr wichtige read_view-Informationen zu speichern.
read_view speichert die Liste aller aktiven Transaktionen im gesamten MySQL, wenn die aktuelle Transaktion gestartet wird, wie in der Abbildung unten gezeigt. Zu den aktiven Transaktionen im System gehören trx4, trx6, trx7 und trx10. Darüber hinaus stellt up_trx_id die kleinste Transaktions-ID in der aktuellen Transaktionsliste dar, wenn die aktuelle Transaktion gestartet wird; low_trx_id stellt die größte Transaktions-ID in der aktuellen Transaktionsliste dar, wenn die aktuelle Transaktion gestartet wird.
read_view ist ein wichtiger Punkt bei der Implementierung von MVCC. Es wird verwendet, um zu bestimmen, welche Version des Datensatzes für die aktuelle Transaktion sichtbar ist. Wenn die aktuelle Transaktion eine bestimmte Zeile von Datensätzen lesen möchte und die Versionsnummer (Transaktions-ID) des Zeilendatensatzes trxid ist, dann:
1 Wenn trxid
2. Wenn trxid > low_trx_id, bedeutet dies, dass die Transaktion, in der sich die Zeile befindet, nach der Erstellung der aktuellen Transaktion geöffnet wurde, sodass der Zeilendatensatz für die aktuelle Transaktion nicht sichtbar ist.
3. Wenn up_trx_id
Nehmen Sie den folgenden Zeilendatensatz als Beispiel. Dieser Zeilendatensatz hat mehrere Versionen (trx2, trx5, trx7 und trx12), von denen trx12 die neueste Version ist. Sehen Sie, welche Version der Zeile für die aktuelle Transaktion sichtbar ist.
1. Die neueste in dieser Zeile aufgezeichnete Version ist trx12. Beim Vergleich mit der aktuellen Transaktion read_view wird festgestellt, dass trx12 größer ist als die größte Transaktion trx10 in der aktuell aktiven Transaktionsliste, was darauf hinweist, dass trx12 geöffnet wurde nachdem die aktuelle Transaktion erstellt wurde, also unsichtbar.
2. Überprüfen Sie, ob die zweitletzte Version des Zeilendatensatzes trx7 ist. Im Vergleich zur aktuellen Transaktion read_view wird festgestellt, dass trx7 zwischen der minimalen Transaktions-ID und der maximalen Transaktions-ID der aktuell aktiven Transaktionsliste liegt Dies zeigt an, dass der Zeilendatensatz Die Transaktion war aktiv, als die aktuelle Transaktion erstellt wurde. Beim Durchlaufen der aktiven Liste wurde festgestellt, dass trx7 vorhanden ist, was darauf hinweist, dass die Transaktion noch nicht übermittelt wurde und daher für die aktuelle Transaktion nicht sichtbar ist.
3. Sehen Sie sich weiterhin die drittneueste Version des Datensatzes an, trx5, die ebenfalls zwischen der minimalen Transaktions-ID und der maximalen Transaktions-ID der aktuell aktiven Transaktionsliste liegt und die Transaktion angibt, in der sich der Zeilendatensatz befindet befindet sich in der aktuellen Transaktion, als die aktuelle Transaktion erstellt wurde. Bei der Durchquerung wurde jedoch festgestellt, dass diese Version nicht in der aktiven Transaktionsliste enthalten ist, was darauf hinweist, dass die Transaktion, die trx5 entspricht, übermittelt wurde (Hinweis: Es besteht keine Korrelation zwischen der Transaktion Übermittlungszeit und Transaktionsnummer Es ist möglich, dass Transaktionen mit größeren Transaktionsnummern zuerst übermittelt werden und Transaktionen mit kleineren Transaktionsnummern später übermittelt werden. Daher ist der Zeilendatensatz der trx5-Version für die aktuelle Transaktion sichtbar und wird direkt zurückgegeben.
Read Committed (technische Interpretation: X-Sperre für Schreib- und Schreibparallelität verwenden, MVCC für Lese- und Schreibparallelität verwenden, um fehlerhafte Lesevorgänge zu vermeiden)
Oben vorgestellt Der MVCC-Technologie-Implementierungsmechanismus in MySQL, aber um die Transaktionssichtbarkeit unter der RC-Isolationsstufe zu verstehen, müssen Sie auch einen Kernpunkt verstehen: Transaktionen unter der RC-Isolationsstufe generieren jedes Mal eine aktuelle read_view, um die ursprüngliche read_view zu ersetzen select wird ausgeführt.
Wie in der Abbildung oben gezeigt, ist die linke Seite Transaktion Nr. 1, und der Datensatz mit der ID = 1 wurde dreimal zu unterschiedlichen Zeitpunkten abgefragt. Auf der rechten Seite befindet sich Transaktion Nr. 2, die den Datensatz mit der ID=1 aktualisiert. Vor dem Update gab es nur eine Version des Datensatzes, nach dem Update waren es jedoch zwei Versionen.
Transaktion Nr. 1 generiert jedes Mal eine aktuelle read_view, wenn sie eine Auswahlanforderung unter der RC-Isolationsstufe ausführt. Die von den ersten beiden Abfragen generierte globale Transaktionsaktivliste enthält trx2, sodass der gefundene Datensatz alt ist MVCC-Vorschriften. Der Zeitpunkt der letzten Abfrage liegt nach der Übermittlung von Transaktion Nr. 2, sodass die generierte globale aktive Transaktionsliste nicht trx2 enthält. Zu diesem Zeitpunkt ist der gemäß den MVCC-Vorschriften gefundene Datensatz die neueste Version aufzeichnen.
Wiederholbares Lesen (technische Interpretation: X-Sperre wird für gleichzeitiges Schreiben und Schreiben verwendet, MVCC wird für gleichzeitiges Lesen und Schreiben verwendet, um nicht wiederholbare Lesevorgänge zu vermeiden; Lückensperre wird für aktuelles Lesen verwendet, um Phantom-Lesevorgänge zu vermeiden)
Anders als im RC-Modus werden Transaktionen im RR-Modus nicht jedes Mal generiert, wenn eine Auswahl ausgeführt wird. Stattdessen wird die read_view generiert, wenn die Transaktion zum ersten Mal ausgewählt wird, und erst wieder geändert Ende der aktuellen Transaktion. Dadurch können nicht wiederholbare Lesevorgänge effektiv vermieden und die von der aktuellen Transaktion gelesenen Daten während des gesamten Transaktionsprozesses konsistent gemacht werden. Das schematische Diagramm lautet wie folgt:
Dies ist leicht zu verstehen. Die von den drei Abfragen verwendete globale aktive Transaktionsliste ist dieselbe und sie werden alle für die read_view generiert Beim ersten Mal müssen die gefundenen Datensätze mit den erstmals gefundenen Datensätzen übereinstimmen.
Kann die RR-Isolationsstufe Phantomlesevorgänge vermeiden?
Wenn Sie sich mit Phantomlesen nicht auskennen, können Sie sich den ersten Artikel dieser Reihe ansehen. Wie in der Abbildung unten gezeigt, führte Transaktion Nr. 1 drei Abfragen zur Filterbedingung für id>1 durch, und Transaktion Nr. 2 führte eine Einfügung durch. Der eingefügte Datensatz erfüllte gerade die Bedingung von id>1. Es ist ersichtlich, dass die durch die drei Abfragen erhaltenen Daten konsistent sind, was durch den MVCC-Mechanismus der RR-Isolationsstufe garantiert wird. Unter diesem Gesichtspunkt wird das Phantomlesen vermieden. Wenn jedoch die letzte Transaktion Nr. 1 einen Datensatz mit der ID = 2 einfügt, gibt MySQL einen Fehler beim doppelten Eintrag zurück. Es ist ersichtlich, dass das Vermeiden des Phantomlesens eine Illusion ist.
Phantom-Lesevorgänge unbedingt vermeiden (technische Interpretation: Der aktuelle Lesevorgang verwendet eine Gap-Sperre, um Phantom-Lesevorgänge zu vermeiden)
Für alle zuvor erwähnten Select-Anweisungen auf RR-Ebene: Wir werden Snapshot-Lesen genannt. Snapshot-Lesen kann nicht wiederholbare Lesevorgänge garantieren, Phantom-Lesevorgänge können jedoch nicht vermieden werden. Daher hat MySQL das Konzept des „aktuellen Lesens“ vorgeschlagen:
1 „select for update“
2
3. Aktualisieren/Löschen
und legt fest, dass die aktuelle Leseanweisung auf RR-Ebene eine spezielle Sperre zum Datensatz hinzufügt – Gap Lock Lock sperrt keinen bestimmten Datensatz, sondern das Intervall zwischen Datensätzen, um sicherzustellen, dass in diesem Intervall keine neuen Datensätze eingefügt werden. Die folgende Abbildung ist ein schematisches Diagramm:
In der Abbildung oben führt Transaktion Nr. 1 zunächst eine aktuell gelesene SELECT-Anweisung aus. Diese Anweisung fügt alle Intervalle mit der ID > 0 hinzu Lückensperre: Wenn Transaktion Nr. 2 die Einfügung mit der ID = 3 ausführt, gibt das System eine Ausnahme zurück, bei der das Sperrwartezeitlimit überschritten wurde. Natürlich können andere Transaktionen unter der Bedingung id
Serialisierbar (technische Interpretation: S-Sperre (Lesen) + Lesevorgänge und aktuelle Lesevorgänge, und alle Schreibvorgänge verfügen über Schreibsperren. Natürlich ist die Leistung dieser Isolationsstufe aufgrund des Sperr-Overheads relativ schlecht.
MySQL-Transaktionspersistenzgarantie
Die MySQL-Transaktionspersistenzstrategie ist grundsätzlich dieselbe wie bei HBase, umfasst jedoch relativ viele Komponenten, hauptsächlich Doublewrite, Redo-Log und Binlog:
1. MySQL-Datenpersistenz (DoubleWrite)
Tatsächlich ist das eigentliche Schreiben von MySQL in zwei Schreibvorgänge unterteilt, von denen einer in eine Datei namens DoubleWrite geschrieben wird und dann tatsächlich geschrieben wird Daten auf die Festplatte, auf der sich die Daten befinden, nachdem der Schreibvorgang erfolgreich war. Warum zweimal schreiben? Dies liegt daran, dass die Größe der MySQL-Datenseite nicht mit der Größe eines atomaren Vorgangs auf der Festplatte übereinstimmt und es zu teilweisen Schreibvorgängen kommen kann. Beispielsweise beträgt die Standardgröße der InnoDB-Datenseite 16 KB und die Größe eines atomaren Schreibvorgangs auf der Festplatte 512 Bytes (Sektorgröße) Das Schreiben einer solchen Datenseite erfordert mehrere E/As. Wenn also in der Mitte eine Ausnahme auftritt, kommt es zu Datenverlust. Darüber hinaus ist zu beachten, dass die Leistung von DoubleWrite keinen großen Einfluss hat, da das Schreiben von DoubleWrite ein sequentielles Schreiben ist, das keine großen Auswirkungen auf die Leistung hat.
2. Redolog-Persistenzstrategie (innodb_flush_log_at_trx_commit)
Redolog ist die WAL von InnoDB. Die Daten werden zuerst in Redolog geschrieben und auf die Festplatte abgelegt und dann auf die Festplatte aktualisiert Pufferpool. Die Persistenzstrategie von Redolog stimmt mit der Persistenzstrategie von hlog in HBase überein. Der Standardwert ist 1, was bedeutet, dass das Protokoll nach jeder Übermittlung auf der Festplatte gespeichert wird etwa alle 1 Sekunde auf die Festplatte übertragen. In diesem Fall ist MySQL möglicherweise ausgefallen und einige Daten können verloren gehen. Dieser Wert ist 2, was bedeutet, dass das Protokoll nach jeder Übermittlung in den Betriebssystempuffer und dann vom Betriebssystem asynchron auf die Festplatte geleert wird. In diesem Fall verliert MySQL keine Daten, wenn es geht Es kann jedoch sein, dass einige Daten verloren gehen, wenn die Maschine ausfällt.
3. Binlog-Persistenzstrategie (sync_binlog)
Binlog zeichnet als Protokollsystem auf Serverebene hauptsächlich verschiedene Vorgänge der Datenbank nacheinander in Form von Ereignissen auf und kann auch die für jeden Vorgang aufgewendete Zeit aufzeichnen. In der offiziellen MySQL-Dokumentation werden hauptsächlich die beiden grundlegendsten Kernfunktionen von Binlog vorgestellt: Sicherung und Replikation. Daher wirkt sich die Persistenz von Binlog in gewissem Maße auf die Integrität der Datensicherung und -replikation aus. Wie bei der Redo-Persistenzstrategie sind die möglichen Werte 0, 1, N. Der Standardwert ist 0, was bedeutet, dass in den Betriebssystempuffer geschrieben und asynchron auf die Festplatte geleert wird. Der Wert 1 gibt synchrone Schreibvorgänge auf die Festplatte an. Wenn N, bedeutet dies, dass alle N Mal, wenn der Betriebssystempuffer geschrieben wird, ein Aktualisierungsvorgang durchgeführt wird.
Zusammenfassend ist dieser Artikel der dritte in einer Reihe von Datenbanktransaktionsartikeln. Er stellt den Kern des zeilenübergreifenden Einzelmaschinen-Transaktionsmodells vor und bietet eine detailliertere Erläuterung der Sperrtechnologie und des MVCC-Mechanismus in Isolation verwickelt. Die damit verbundenen Merkmale wie Transaktionsatomizität und Haltbarkeit werden ebenfalls kurz analysiert und erläutert. Als Nächstes führt Sie der Autor dazu, über das verteilte Transaktionsmodell zu sprechen und zu sehen, wie es sich vom eigenständigen Transaktionsmodell unterscheidet.
Empfohlenes Lernen: MySQL-Tutorial
Das obige ist der detaillierte Inhalt vonMySQL-Zeilenübergreifendes Transaktionsmodell (detaillierte grafische Erklärung). Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!
