Eine kurze Analyse der zugrunde liegenden Prinzipien von MySQL-Transaktionen und Isolationsebenen

Vorwort

Lassen Sie uns zunächst überprüfen, was eine Transaktion ist. Eine Transaktion ist die kleinste Arbeitseinheit für Datenbankoperationen. Es handelt sich um eine Reihe von Operationen, die als eine einzige logische Arbeitseinheit ausgeführt werden. Diese Operationen werden dem System als Ganzes übermittelt und entweder alle ausgeführt oder nicht ausgeführt. Eine Transaktion ist eine Reihe unteilbarer Operationen (logische Arbeitseinheit).

Merkmale der Transaktionen:

Atomarität: Atomarität bedeutet, dass alle in einer Transaktion enthaltenen Vorgänge entweder vollständig erfolgreich sind oder vollständig fehlschlagen und zurückgesetzt werden. Konsistenz: Das Ergebnis der Transaktionsausführung muss darin bestehen, die Datenbank von einem konsistenten Zustand in einen anderen konsistenten Zustand zu ändern. Isolation: Die Ausführung einer Transaktion kann nicht durch andere Transaktionen gestört werden. Das heißt, die innerhalb einer Transaktion verwendeten Vorgänge und Daten sind von anderen gleichzeitigen Transaktionen isoliert, und gleichzeitig ausgeführte Transaktionen können sich nicht gegenseitig stören. Dauerhaftigkeit: Sobald eine Transaktion bestätigt wurde, sollten die an den Daten in der Datenbank vorgenommenen Änderungen dauerhaft sein. Nachfolgende andere Vorgänge oder Fehler sollten keinen Einfluss auf die Ausführungsergebnisse haben.

1. Kurze Analyse der zugrunde liegenden Transaktionsprinzipien

Atomarität:

Implementierungsprinzip: Undo-Log

Das Undo-Protokoll wird auch Rollback-Protokoll genannt und bildet die Grundlage für die Atomarität und Isolierung von Transaktionen. Wenn eine Transaktion die Datenbank ändert, generiert InnoDB ein entsprechendes Undo-Protokoll. Wenn die Transaktion fehlschlägt oder ein Rollback aufgerufen wird, wodurch die Transaktion zurückgesetzt wird, können die Informationen im Undo-Protokoll verwendet werden, um die Daten auf den Zustand vor der Änderung zurückzusetzen.

Das Undo-Protokoll ist ein logisches Protokoll, das Informationen zur SQL-Ausführung aufzeichnet. Wenn ein Rollback erfolgt, führt InnoDB gemäß dem Inhalt des Undo-Protokolls das Gegenteil der vorherigen Arbeit aus: Für jeden Einschub wird beim Rollback ein Löschvorgang ausgeführt; für jeden Löschvorgang wird beim Rollback ein Einschub ausgeführt; für jede Aktualisierung wird beim Rollback eine entgegengesetzte Aktualisierung ausgeführt, um die Daten wieder zu ändern.

Das Rückgängigmachen wird in einem speziellen Segment innerhalb der Datenbank gespeichert, das als Undo-Segment bezeichnet wird. Das Undo-Segment befindet sich im gemeinsam genutzten Tablespace. „Rückgängig“ ist ein logisches Protokoll und stellt daher nur den ursprünglichen Zustand der Datenbanklogik wieder her. Das Undo-Protokoll generiert ein Redo-Protokoll, d. h. die Generierung des Undo-Protokolls wird von der Generierung eines Redo-Protokolls begleitet, da das Undo-Protokoll auch dauerhaften Schutz benötigt.

Der Undo-Log-Ausführungsdatensatz wird vor dem Schreiben oder Ändern aller Daten erstellt.

Prinzip der Undo-Log-Verwendung: Jede Datenzeile in der Datenbanktabelle hat zwei weitere Spalten, DATA_TRX_ID und DATA_ROLL_PTR (es kann auch eine Spalte DB_ROW_ID geben, die automatisch hinzugefügt wird, wenn kein Standardprimärschlüssel vorhanden ist). DATA_TRX_ID gibt die Transaktionsversion der aktuellen Daten an, und DATA_ROLL_PTR zeigt auf die Transaktionsversion, die gerade kopiert wurde.

Der alte Versionsdatensatz in der Undo-Log-Kette. Das Undo-Log ist eine verknüpfte Liste. Wenn mehrere Transaktionen die Datei mehrfach ändern, werden weiterhin Undo-Logs generiert und eine Zeigerbeziehung wird über DATA_ROLL_PTR hergestellt. Lassen Sie mich dies anhand eines Bildes veranschaulichen:

Auf diese Weise kann MySQL nach dem Zurücksetzen der Transaktion die Daten mithilfe des Undo-Protokolls wiederherstellen und so die Atomizität nicht festgeschriebener Transaktionen sicherstellen.

Persistenz

Implementierungsprinzip: Redo-Log

Da InnoDB die Speicher-Engine von MySQL ist, werden Daten auf der Festplatte gespeichert. Um die Festplatten-E/A zu reduzieren und die Leseleistung zu verbessern, bietet InnoDB einen Cache-Pool – Buffer Pool. Der Pufferpool enthält die Zuordnung einiger Datenseiten auf der Festplatte, die als Puffer für den Zugriff auf die Datenbank dient: Beim Lesen von Daten aus der Datenbank werden diese zuerst aus dem Pufferpool gelesen. Wenn sich die Daten nicht im Pufferpool befinden, werden sie von der Festplatte gelesen und dann in den Pufferpool geschrieben. Beim Schreiben von Daten in die Datenbank werden diese zuerst in den Pufferpool geschrieben. Die geänderten Daten im Pufferpool werden regelmäßig auf die Festplatte aktualisiert (dieser Vorgang wird als Leeren bezeichnet).

Dies bringt jedoch auch ein neues Problem mit sich: Wenn MySQL abstürzt und die geänderten Daten im Pufferpool nicht auf die Festplatte aktualisiert wurden, gehen Daten verloren und die Persistenz der Transaktion kann nicht garantiert werden.

Um dieses Problem zu lösen, wurde Redo Log, auch Redo-Log genannt, eingeführt. Wenn Daten geändert werden, wird der Vorgang nicht nur im Pufferpool geändert, sondern auch im Redo-Protokoll aufgezeichnet. Wenn die Transaktion festgeschrieben wird, wird die fsync-Schnittstelle aufgerufen, um das Redo-Protokoll auf die Festplatte zu schreiben. Sollte MySQL abstürzen, können Sie beim Neustart die Daten im Redo-Log auslesen und die Datenbank wiederherstellen. Das Redo-Protokoll verwendet WAL (Write-ahead logging). Alle Änderungen werden vor der Übermittlung in das Protokoll geschrieben. Dadurch wird sichergestellt, dass aufgrund von MySQL-Ausfallzeiten keine Daten verloren gehen und die Persistenzanforderungen erfüllt werden. Das Redo-Log ist für physische Seiten und wird gleichzeitig ausgeführt. Das letzte Commit überschreibt die nicht festgeschriebenen Daten. Lokales Redo-Log:

Das Redo-Log verfügt auch über einen Puffer – den Redo-Log-Puffer. Wenn die Transaktion festgeschrieben wird, werden alle Änderungsinformationen auf der Festplatte aktualisiert. Benutzer können die Aktualisierungsrichtlinie auch ändern, indem sie den Wert der Variable innodb_flush_log_at_trx_commit (Standard 1) steuern. Wenn der Wert beispielsweise auf 2 gesetzt ist, wird die Aktualisierung so gesteuert, dass sie jede Sekunde erfolgt, sodass Transaktionen

Die Transaktion wird zwar schneller durchgeführt, es besteht jedoch die Gefahr eines Protokollverlusts.

Das Redo-Log wird nach der Ausführung der SQL-Anweisung aufgezeichnet.

Da das Redo-Protokoll auch gespeichert werden muss und Festplatten-E/A umfasst, warum verwenden wir es trotzdem?

(1) Die Speicherung des Redo-Logs erfolgt sequentiell, während die Cache-Synchronisierung ein zufälliger Vorgang ist.

(2) Die Cache-Synchronisierung basiert auf Datenseiten und die Größe der jedes Mal übertragenen Daten ist größer als das Redo-Protokoll.

Das Redo-Protokoll wird verwendet, um Daten wiederherzustellen und die Beständigkeit festgeschriebener Transaktionen sicherzustellen.

Isolierung:

Prinzip:
(1) Auswirkungen von Schreibvorgängen auf Schreibvorgänge: Sperrmechanismus sorgt für Isolation
(2) Einfluss von Schreibvorgängen auf Lesevorgänge: MVCC sorgt für Isolation

Konsistenz:

Konsistenz ist etwas ganz Besonderes. Die bereits erwähnte Atomizität, Persistenz und Isolation dienen alle der Konsistenz. Darüber hinaus beruht Konsistenz auch auf den Garantien, die die Datenbank selbst bietet, wie z. B. SQL-Syntaxüberprüfung, Überprüfung des Datentyps beim Einfügen von Spaltentypen und auch auf den Garantien, die die Anwendungsschicht bietet. Beispielsweise müssen Entwickler bei einer Überweisungsoperation den Saldo des Übertragenden abziehen und den Saldo des Empfängers erhöhen. Wenn auf Anwendungsebene ein Problem auftritt, kann Konsistenz nicht garantiert werden.

2. Analyse der zugrunde liegenden Prinzipien der Isolationsebenen

Da das Isolationsprinzip bei der Analyse der zugrunde liegenden Transaktionsprinzipien nicht ausführlich erörtert wurde, stellen wir es hier kurz vor.

Lassen Sie mich zunächst MySQLs MVCC (MultiVersion Concurrency Control) vorstellen, was als Multiversion Concurrency Control bezeichnet wird. Die Implementierung erfolgt durch Rückgängigmachen des Protokolls und Lesen der Ansicht . Das Undo-Protokoll wurde oben bereits vorgestellt und wird hier nicht wiederholt. Die Leseansicht unterscheidet sich von der Datenbankansicht, die wir normalerweise verstehen. Sie wird verwendet, um die Sichtbarkeit der aktuellen Datenversion zu bestimmen.

ReadView hat vier Haupteigenschaften:

(1). m_ids stellt alle aktuell aktiven Transaktions-IDs dar, wenn die ReadView generiert wird. Aktiv bedeutet, dass die Transaktion gestartet, aber noch nicht festgeschrieben wurde.

(2). min_trx_id gibt die kleinste Transaktions-ID unter den aktuell aktiven mIds an;

(3). max_trx_id gibt die maximale Transaktions-ID beim Generieren von ReadView an, die nicht unbedingt die größte Transaktions-ID in mIds sein muss;

(4).creator_trx_id gibt die Transaktions-ID an, die den ReadView erstellt hat.

Hinweis: Bei jedem Öffnen einer Transaktion wird die Transaktions-ID einmal erhöht. Die Transaktions-ID kann als globale Autoinkrementvariable betrachtet werden. Die erste geöffnete Transaktion wird möglicherweise nicht vor den späteren Transaktionen festgeschrieben (z. B. bei langen Verbindungen). Gehen Sie daher nicht davon aus, dass max_trx_id der Maximalwert in mIds ist.

Wie verwendet die Lese-Ansicht die oben genannten vier Attribute, um zu bestimmen, welche Datenversion eine Transaktion lesen soll?

Wenn die data_trx_id der aufgerufenen Version kleiner als der Mindestwert in m_ids ist, bedeutet dies, dass die Transaktion, die die Version generiert hat, vor der Generierung von ReadView festgeschrieben wurde und auf die Version von der aktuellen Transaktion zugegriffen werden kann.

Wenn der data_trx_id-Attributwert der aufgerufenen Version mit dem creator_trx_id-Wert in ReadView übereinstimmt, bedeutet dies, dass die aktuelle Transaktion auf den Datensatz zugreift, den sie geändert hat, sodass die Version von der aktuellen Transaktion aufgerufen werden kann.

Wenn der data_trx_id-Attributwert der aufgerufenen Version größer als der max_trx_id-Wert in ReadView ist, bedeutet dies, dass die Transaktion, die diese Version generiert hat, geöffnet wurde, nachdem die aktuelle Transaktion ReadView generiert hat. Auf diese Version kann daher von der aktuellen Transaktion nicht zugegriffen werden.

Wenn der Attributwert data_trx_id der aufgerufenen Version zwischen min_trx_id und max_trx_id der ReadView liegt, muss ermittelt werden, ob der Attributwert trx_id in der m_ids-Liste enthalten ist. Wenn dies der Fall ist, bedeutet dies, dass die Transaktion, die die Version beim Erstellen der ReadView generiert hat, noch aktiv ist und auf die Version nicht zugegriffen werden kann. Wenn dies nicht der Fall ist, bedeutet dies, dass die Transaktion, die die Version beim Erstellen der ReadView generiert hat, festgeschrieben wurde und auf die Version zugegriffen werden kann.

Wenn eine Transaktion eine Datenzeile lesen möchte, verwendet sie zunächst die oben genannten Regeln, um die neueste Version der Daten, d. h. die Datensatzzeile, zu ermitteln. Wenn festgestellt wird, dass sie zugänglich ist, wird sie direkt gelesen. Wenn festgestellt wird, dass sie nicht zugänglich ist, findet sie das Undo-Protokoll über den DATA_ROLL_PTR-Zeiger und sucht rekursiv nach jeder Version, bis sie die Version liest, die sie lesen kann. Wenn sie nicht gelesen werden kann, wird sie leer zurückgegeben.

Daher wird beim Zugriff auf Daten eine Ansicht in der Datenbank erstellt und das logische Ergebnis der Ansicht als Grundlage für den Zugriff verwendet:

READ UNCOMMITED (uncommitted read): Diese Isolationsebene gibt direkt den neuesten Wert im Datensatz zurück und es gibt kein Ansichtskonzept. Da beim Lesen keine Sperren hinzugefügt werden, werden beim Schreibvorgang die Daten während des Lesevorgangs geändert, was zu fehlerhaften Lesevorgängen führt. Der Vorteil besteht darin, dass die Leistung der gleichzeitigen Verarbeitung verbessert und paralleles Lesen und Schreiben ermöglicht wird.

READ COMMITED : Unter dieser Isolationsebene wird diese Ansicht zu Beginn jeder SQL-Anweisungsausführung erstellt. InnoDB verwendet exklusive Sperren in READ COMMITTED und verwendet den MVCC-Mechanismus, anstatt Daten beim Lesen zu sperren. Mit anderen Worten: Es wird ein Lese- und Schreibtrennungsmechanismus eingesetzt.

WIEDERHOLBARES LESEN : Auf dieser Isolationsebene wird die Ansicht beim Start der Transaktion erstellt und während der gesamten Transaktion verwendet.

SERIALIZABLE : Diese Isolationsebene verwendet direkt Sperren, um parallelen Zugriff zu verhindern.

An diesem Punkt haben Sie möglicherweise festgestellt, dass MySQL mithilfe von MVCC Phantomlesevorgänge auf der Isolationsebene für wiederholbare Lesevorgänge tatsächlich verhindern kann.

Abschluss

Atomizität: Verwenden Sie das Undo-Protokoll (Rollback-Protokoll), um ein Rollback zu implementieren und so die Atomizität nicht festgeschriebener Transaktionen sicherzustellen.

Persistenz: Verwenden Sie ein Redo-Protokoll, um eine Datenwiederherstellung zu erreichen und so die Persistenz festgeschriebener Transaktionen sicherzustellen.

Isolierung: Verwenden Sie Sperren und MVCC-Ideen, um Lese-/Schreibtrennung, Lese-/Lese-Parallelität und Lese-/Schreib-Parallelität zu erreichen.

Konsistenz: Erreichen Sie Konsistenz durch Rollback, Wiederherstellung und Isolierung in gleichzeitigen Umgebungen.

Dies ist das Ende dieses Artikels über die zugrunde liegenden Prinzipien von MySQL-Transaktionen und Isolationsebenen. Weitere Informationen zu MySQL-Transaktionen und Isolationsebenen finden Sie in früheren Artikeln auf 123WORDPRESS.COM oder in den folgenden verwandten Artikeln. Ich hoffe, Sie werden 123WORDPRESS.COM auch in Zukunft unterstützen!