Was sind die Merkmale des MySQL-Transaktionsprotokolls?

1. MySQL-Transaktionen

Transaktionen sind ein wichtiges Merkmal, das MySQL von NoSQL unterscheidet und die Schlüsseltechnologie zur Gewährleistung der Datenkonsistenz in relationalen Datenbanken . Eine grundlegende Ausführungseinheit, die aus einer oder mehreren SQL-Anweisungen besteht, kann als Vorgang einer Transaktion in der Datenbank betrachtet werden. Wenn diese Anweisungen ausgeführt werden, werden entweder alle oder keine davon ausgeführt.

Die Ausführung einer Transaktion umfasst hauptsächlich zwei Vorgänge: Commit und Rollback.

Senden: Festschreiben, Schreiben der Ergebnisse der Transaktionsausführung in die Datenbank.

Rollback: Rollback, alle ausgeführten Anweisungen zurücksetzen und die Daten vor der Änderung zurückgeben.

MySQL-Transaktionen umfassen vier Merkmale, die als die vier ACID-Könige bekannt sind.

Atomizität: Anweisungen werden entweder vollständig ausgeführt oder überhaupt nicht ausgeführt. Die Transaktion selbst wird hauptsächlich durch das Rückgängigmachen-Protokoll definiert Protokollimplementierung.

Dauerhaftigkeit (Durability): Stellen Sie sicher, dass Daten aufgrund von Ausfallzeiten und anderen Gründen nach der Transaktionseinreichung nicht verloren gehen.

Isolation (Isolation). ): Die Ausführung von Transaktionen wird so weit wie möglich von anderen Transaktionen beeinflusst. Die Implementierung von RR basiert hauptsächlich auf dem Sperrmechanismus, dem Rückgängig-Protokoll und dem Sperrmechanismus für den nächsten Schlüssel. 🎜🎜#

Konsistenz: Das von Transaktionen verfolgte ultimative Ziel erfordert sowohl Garantien auf Datenbankebene als auch Garantien auf Anwendungsebene Dies bedeutet, dass die Transaktion nicht weiter unterteilt werden kann oder dass keine der Operationen ausgeführt werden kann. Wenn eine SQL-Anweisung in der Transaktion nicht ausgeführt werden kann, muss die ausgeführte Anweisung ebenfalls zurückgesetzt werden. und die Datenbank kehrt in den Zustand vor der Transaktion zurück. Es gibt nur 0 und 1 und keine anderen Werte.

Die Atomizität der Transaktion zeigt an, dass die Transaktion nicht ausgeführt werden kann Erfolgreich ist es erforderlich, alle in der Transaktion ausgeführten Anweisungen zurückzusetzen, damit die Datenbank in den Zustand zurückkehrt, in dem die Transaktion nicht gestartet wurde.

Die Atomizität der Transaktion wird erreicht Das Rückgängig-Protokoll, wenn die Transaktion zurückgesetzt werden muss. Zu diesem Zeitpunkt ruft die InnoDB-Engine das Rückgängig-Protokoll auf, um die SQL-Anweisung rückgängig zu machen und das Rollback der Daten zu realisieren Die Datenbank sollte dauerhaft und nicht vorübergehend gespeichert werden, unabhängig davon, welcher Vorgang oder welche Systemausfallzeit auftritt, die ursprünglichen Ausführungsergebnisse werden nach dem Festschreiben der Transaktion nicht beeinträchtigt über das Redo-Log in der InnoDB-Speicher-Engine. Spezifische Implementierungsideen finden Sie weiter unten selbst, während sich die Isolation auf die Beziehung bezieht, die zwischen Transaktionen aufrechterhalten werden sollte. Die Auswirkungen verschiedener Transaktionen sollten voneinander isoliert sein. #🎜🎜 #Da eine Transaktion möglicherweise nicht nur eine SQL-Anweisung enthält, ist es sehr wahrscheinlich, dass während der Ausführung der Transaktion mit der Ausführung anderer Transaktionen begonnen wird. Daher erfordert die Parallelität mehrerer Transaktionen die Ausführung von Transaktionen Dies ähnelt in gewisser Weise dem Konzept der Datensynchronisation zwischen mehreren Threads. Wenn eine Transaktion eine bestimmte Datenzeile in der Datenbank ändern muss, müssen sie zuerst gesperrt werden Transaktionen führen keine Vorgänge für die gesperrten Daten aus und können nur darauf warten, dass die aktuelle Transaktion die Sperre aufhebt Der Sperrmechanismus ist kein unbekanntes Konzept. In MySQL können Sperren auch nach unterschiedlichen Aufteilungsstandards in verschiedene Typen unterteilt werden.

Unterteilt nach Granularität: Zeilensperre, Tabellensperre, Seitensperre

Unterteilt nach Verwendung: Gemeinsame Sperre, Exklusive Sperre

#🎜🎜 #Nach Ideen unterteilt: pessimistisches Schloss, optimistisches Schloss

Es gibt viele Wissenspunkte zum Schlossmechanismus, aber aus Platzgründen werde ich sie alle besprechen. Hier finden Sie eine kurze Einführung in Sperren, unterteilt nach Granularität.

Granularität: bezieht sich auf den Grad der Verfeinerung oder Vollständigkeit der in der Dateneinheit des Data Warehouse gespeicherten Daten. Je höher der Verfeinerungsgrad, desto kleiner der Granularitätsgrad; umgekehrt gilt: Je niedriger der Verfeinerungsgrad, desto größer der Granularitätsgrad.

MySQL kann entsprechend der Granularität der Sperren in Zeilensperren, Tabellensperren und Seitensperren unterteilt werden.

Zeilensperre: Die Sperre mit der kleinsten Granularität, was bedeutet, dass nur die Zeile des aktuellen Vorgangs gesperrt ist; #Tabellensperre: Die Sperre mit der größten Granularität bedeutet, dass der aktuelle Vorgang die gesamte Tabelle sperrt Sperren auf Tabellenebene zeigen an, dass die Seite gesperrt ist.

Granulare Aufteilung der Datenbank

Diese drei Arten von Sperren sperren Daten auf unterschiedlichen Ebenen Unterschiedliche Granularität, die Vor- und Nachteile sind ebenfalls unterschiedlich.

Die Tabellensperre sperrt die gesamte Tabelle, wenn Daten verarbeitet werden, sodass die Parallelitätsleistung schlecht ist.

Die Zeilensperre sperrt nur die Daten, die verarbeitet werden müssen, und die Parallelitätsleistung ist gut. Da das Sperren selbst jedoch Ressourcen verbraucht (das Erhalten von Sperren, das Überprüfen von Sperren, das Freigeben von Sperren usw. verbraucht alle Ressourcen), kann die Verwendung von Tabellensperren viele Ressourcen einsparen, wenn viele gesperrte Daten vorhanden sind.

Verschiedene Speicher-Engines in MySQL unterstützen unterschiedliche Sperren. MyIsam unterstützt nur Tabellensperren, während InnoDB sowohl Tabellensperren als auch Zeilensperren unterstützt. Aus Leistungsgründen werden in den meisten Fällen Zeilensperren verwendet.

Gleichzeitige Lese- und Schreibprobleme

In einer gleichzeitigen Situation kann das gleichzeitige Lesen und Schreiben von MySQL drei Arten von Problemen verursachen: Dirty Reads, Nichtwiederholbarkeit und Phantom Reads.

(1) Dirty Reading: Die aktuelle Transaktion liest nicht festgeschriebene Daten aus anderen Transaktionen, bei denen es sich um Dirty Data handelt.

Wenn Transaktion A im obigen Beispielszenario das Lesevolumen des Artikels liest, erhält sie die Daten, die Transaktion B noch nicht übermittelt hat. Wenn Transaktion B am Ende nicht erfolgreich übermittelt wird, was dazu führt, dass die Transaktion zurückgesetzt wird, wird der Lesebetrag nicht tatsächlich erfolgreich geändert, aber Transaktion A liest den geänderten Wert, was offensichtlich unangemessen ist.

(2) Nicht wiederholbares Lesen: Dieselben Daten werden in Transaktion A zweimal gelesen, aber die Ergebnisse der beiden Lesevorgänge sind unterschiedlich. Der Unterschied zwischen Dirty Read und Non-Repeatable Read besteht darin, dass ersteres nicht festgeschriebene Daten von anderen Transaktionen liest, während letzteres Daten liest, die von anderen Transaktionen übermittelt wurden.

Wenn beispielsweise Transaktion A die Daten des Artikellesevolumens nacheinander liest, erhält sie unterschiedliche Ergebnisse. Dies bedeutet, dass während der Ausführung von Transaktion A der Wert des Lesevolumens durch andere Transaktionen geändert wurde. Dadurch sind die Ergebnisse der Datenabfrage nicht mehr zuverlässig und auch unrealistisch.

Nach dem Umschreiben: Wenn in Transaktion A zwei Datenbankabfragen gemäß einer bestimmten Bedingung ausgeführt werden, ist die Anzahl der Zeilen in den Abfrageergebnissen unterschiedlich, was zum Phänomen des Phantomlesens führt. Die ursprünglichen Wörter können wie folgt umgeschrieben werden: Im Vergleich zum Phantomlesen gleicht das nicht wiederholbare Lesen eher einer Änderung der Daten, also einer Änderung der Anzahl der Datenzeilen.

Nehmen wir das obige Bild als Beispiel: Bei der Abfrage von Artikeln mit 0

Isolationsstufen

Basierend auf den oben genannten drei Problemen werden vier Isolationsstufen generiert, die unterschiedliche Grade der Isolationseigenschaften der Datenbank angeben.

Im tatsächlichen Datenbankdesign ist die Parallelitätseffizienz der Datenbank umso geringer, und wenn die Isolationsstufe zu niedrig ist, treten während des Lese- und Schreibvorgangs verschiedene Probleme auf.

In den meisten Datenbanksystemen ist die Standardisolationsstufe also „Read Committed“ (z. B. Oracle) oder „Repeatable Read RR“ (InnoDB-Engine von MySQL).

MVCC

Ein weiteres großes Stück, das schwer zu kauen ist. MVCC wird verwendet, um die dritte Isolationsebene oben zu implementieren, die RR wiederholt lesen kann.

Multi-Version Concurrency Control, auch bekannt als MVCC, ist ein Parallelitätskontrollprotokoll, das mehrere Datenversionen unterstützen kann.

Das Merkmal von MVCC besteht darin, dass verschiedene Transaktionen gleichzeitig unterschiedliche Datenversionen lesen können, wodurch die Probleme von Dirty Reads und nicht wiederholbaren Lesevorgängen gelöst werden.

MVCC erreicht tatsächlich die Koexistenz mehrerer Datenversionen durch versteckte Datenspalten und Rollback-Protokolle (Rückgängig-Protokoll). Dies hat den Vorteil, dass bei Verwendung von MVCC zum Lesen von Daten keine Sperre erforderlich ist, wodurch Konflikte beim gleichzeitigen Lesen und Schreiben vermieden werden.

Bei der Implementierung von MVCC werden in jeder Datenzeile mehrere zusätzliche ausgeblendete Spalten gespeichert, z. B. die Versionsnummer und der Löschzeitpunkt, als die aktuelle Zeile erstellt wurde, sowie der Rollback-Zeiger auf das Rückgängig-Protokoll. Die Versionsnummer ist hier nicht der tatsächliche Zeitwert, sondern die Systemversionsnummer. Bei jedem Start einer neuen Transaktion wird die Systemversionsnummer automatisch erhöht. Zu Beginn einer Transaktion wird der Systemversionsnummer die Transaktionsversionsnummer zum Vergleich mit der Versionsnummer jeder abgefragten Datensatzzeile zugewiesen.

Jede Transaktion hat ihre eigene Versionsnummer. Wenn Datenoperationen innerhalb der Transaktion ausgeführt werden, wird der Zweck der Datenversionskontrolle durch den Vergleich der Versionsnummern erreicht.

Darüber hinaus kann die von InnoDB implementierte Isolationsstufe RR das Phänomen des Phantomlesens vermeiden, was durch den Next-Key-Sperrmechanismus erreicht wird.

Next-Key-Sperre ist eigentlich eine Art Zeilensperre, sperrt jedoch nicht nur den aktuellen Zeilendatensatz selbst, sondern auch einen Bereich. Wenn Sie beispielsweise im obigen Beispiel einer Phantomlesung mit der Abfrage von Artikeln mit 0

Lückensperre: Lücken in Indexdatensätzen blockieren

Obwohl InnoDB die Next-Key-Sperre verwendet, um Phantomleseprobleme zu vermeiden, handelt es sich dabei nicht um eine wirklich serialisierbare Isolation. Schauen wir uns ein anderes Beispiel an.

Lassen Sie mich zunächst eine Frage stellen:

Schätzen Sie zum Zeitpunkt T6, nachdem Transaktion A die Transaktion festgeschrieben hat, wie hoch das Lesevolumen von Artikel A und Artikel B ist?

Die Antwort ist, dass das Lesevolumen des Artikels AB auf 10.000 geändert wurde. Dies bedeutet, dass sich die Einreichung von Transaktion B tatsächlich auf die Ausführung von Transaktion A auswirkt, was ein weiterer Hinweis darauf ist, dass die beiden Transaktionen nicht vollständig unabhängig sind. Obwohl das Phänomen des Phantomlesens vermieden werden kann, erreicht es nicht das Niveau der Serialisierbarkeit.

Die notwendige Bedingung zum Erreichen der serialisierbaren Isolationsstufe besteht darin, schmutzige Lesevorgänge, nicht wiederholbare Lesevorgänge und Phantomlesevorgänge zu vermeiden. Dies reicht jedoch nicht aus. Durch die Serialisierbarkeit können Dirty Reads, nicht wiederholbare Lesevorgänge und Phantom Reads vermieden werden. Durch die Vermeidung von Dirty Reads, nicht wiederholbaren Lesevorgängen und Phantom Reads wird jedoch nicht unbedingt Serialisierbarkeit erreicht.

Konsistenz

Konsistenz bedeutet, dass nach der Ausführung der Transaktion die Integritätsbeschränkungen der Datenbank nicht zerstört werden und der Datenstatus vor und nach der Ausführung der Transaktion legal ist.

Konsistenz ist das ultimative Ziel von Transaktionen. Atomarität, Haltbarkeit und Isolation dienen tatsächlich dazu, die Konsistenz des Datenbankstatus sicherzustellen.

Mehr gibt es nicht zu sagen. Sie probieren sorgfältig.

2. MySQL-Protokollierungssystem

Nachdem ich die Grundstruktur von MySQL kennengelernt habe, habe ich jetzt ein relativ genaues Verständnis des Ausführungsprozesses von MySQL. Als nächstes werde ich Ihnen das Protokollierungssystem vorstellen.

Das MySQL-Protokollierungssystem ist ein wichtiger Bestandteil der Datenbank und wird zum Aufzeichnen von Aktualisierungen und Änderungen an der Datenbank verwendet. Bei einem Datenbankausfall können die Originaldaten der Datenbank über verschiedene Protokolldatensätze wiederhergestellt werden. Daher bestimmt das Protokollsystem tatsächlich direkt die Robustheit und Robustheit des MySQL-Betriebs.

MySQL verfügt über viele Arten von Protokollen, z. B. Binärprotokolle (Binlog), Fehlerprotokolle, Abfrageprotokolle, langsame Abfrageprotokolle usw. Darüber hinaus bietet die InnoDB-Speicher-Engine zwei Arten von Protokollen: Redo-Protokolle (Redo-Protokolle) und Protokoll rückgängig machen (Protokoll zurückgeben). Hier konzentrieren wir uns auf die InnoDB-Engine und analysieren die drei Arten von Redo-Logs, Rollback-Logs und Binärlogs.

Redo-Protokoll (Redo-Protokoll)

Das Redo-Protokoll (Redo-Protokoll) ist das Protokoll der InnoDB-Engine-Schicht. Es wird zum Aufzeichnen von Datenänderungen verwendet, die durch Transaktionsvorgänge verursacht werden, und zeichnet die physische Änderung von Datenseiten auf.

Die Funktion des Redo-Tagebuchs ist eigentlich leicht zu verstehen, lassen Sie mich eine Analogie verwenden. Die Änderung von Daten in der Datenbank ist wie eine Arbeit, die Sie geschrieben haben. Was passiert, wenn die Arbeit eines Tages verloren geht? Um diesem unglücklichen Vorfall vorzubeugen, können wir beim Schreiben einer Arbeit ein kleines Notizbuch führen, in dem wir jede Änderung aufzeichnen und aufzeichnen, wann und welche Art von Änderungen an einer bestimmten Seite vorgenommen wurden. Dies ist das Redo-Log.

Die InnoDB-Engine aktualisiert Daten, indem sie zunächst den Aktualisierungsdatensatz in das Redo-Protokoll schreibt und dann den Inhalt des Protokolls auf die Festplatte aktualisiert, wenn das System inaktiv ist oder gemäß der festgelegten Aktualisierungsstrategie. Die sogenannte Write-Ahead-Protokollierungstechnologie (Write-Ahead-Protokollierung). Diese Technologie kann die Häufigkeit von E/A-Vorgängen erheblich reduzieren und die Effizienz der Datenaktualisierung verbessern.

Dirty Data Flushing

Es ist zu beachten, dass die Größe des Redo-Logs festgelegt ist. Um kontinuierlich Aktualisierungsdatensätze zu schreiben, sind im Redo-Log zwei Flag-Positionen festgelegt: checkpoint und write_pos, die jeweils die Position darstellen Die Löschung wird aufgezeichnet und die Position, an der geschrieben wird, wird aufgezeichnet. Das Datenschreibdiagramm des Redo-Logs ist in der folgenden Abbildung zu sehen.

Wenn das write_pos-Flag das Ende des Protokolls erreicht, springt es vom Ende zum Kopf des Protokolls, um es wieder in Umlauf zu bringen. Daher ist die logische Struktur des Redo-Protokolls nicht linear, sondern kann als kreisförmige Bewegung betrachtet werden. Der Raum zwischen write_pos und checkpoint kann zum Schreiben neuer Daten genutzt werden. Das Schreiben und Löschen erfolgt zyklisch hin und her.

Wenn write_pos den Prüfpunkt einholt, bedeutet dies, dass das Redo-Protokoll voll ist. Zu diesem Zeitpunkt können Sie keine weiteren Datenbankaktualisierungsanweisungen ausführen. Sie müssen zuerst einige Datensätze anhalten und löschen und Prüfpunktregeln ausführen, um beschreibbaren Speicherplatz freizugeben.

Checkpoint-Regeln: Nachdem der Checkpoint ausgelöst wurde, werden sowohl fehlerhafte Datenseiten als auch fehlerhafte Protokollseiten im Puffer auf die Festplatte geleert.

Verschmutzte Daten: Bezieht sich auf die Daten im Speicher, die nicht auf die Festplatte geleert wurden.

Das wichtigste Konzept im Redo-Log ist der Pufferpool. Dabei handelt es sich um einen im Speicher zugewiesenen Bereich, der die Zuordnung einiger Datenseiten auf der Festplatte enthält und als Puffer für den Zugriff auf die Datenbank dient.

Wenn eine Anfrage zum Lesen von Daten gestellt wird, wird zunächst festgestellt, ob ein Treffer im Pufferpool vorliegt. Wenn ein Treffer fehlschlägt, wird er auf der Festplatte abgerufen und in den Pufferpool gestellt Wenn eine Anforderung zum Schreiben von Daten gestellt wird, werden diese zuerst in den Pufferpool geschrieben. Die geänderten Daten im Pufferpool werden regelmäßig auf die Festplatte geleert. Dieser Vorgang wird auch Bürsten genannt.

Wenn die Daten geändert werden, wird der Vorgang daher zusätzlich zur Änderung der Daten im Pufferpool auch im Redo-Protokoll aufgezeichnet. Wenn die Transaktion übermittelt wird, werden die Daten basierend auf den Redo-Log-Datensätzen geleert . Sollte MySQL ausfallen, können beim Neustart die Daten im Redo-Log ausgelesen und die Datenbank wiederhergestellt werden, wodurch die Haltbarkeit der Transaktionen gewährleistet und die Datenbank absturzsicher gemacht wird.

Dirty-Log-Flushing

Zusätzlich zum oben erwähnten Flushen von Dirty-Daten ist es bei der Aufzeichnung des Redo-Logs tatsächlich auch erforderlich, die Protokolldatensätze zu schreiben, um die Persistenz der Protokolldatei sicherzustellen vom Speicher zum Festplattenprozess. Das Redo-Log-Protokoll kann in zwei Teile unterteilt werden: der Cache-Log-Redo-Log-Buff, der im flüchtigen Speicher vorhanden ist, und der andere Teil ist die auf der Festplatte gespeicherte Redo-Log-Datei. Um sicherzustellen, dass jeder Datensatz in das Protokoll auf der Festplatte geschrieben werden kann, wird der fsync-Vorgang des Betriebssystems jedes Mal aufgerufen, wenn das Protokoll im Redo-Log-Puffer in die Redo-Log-Datei geschrieben wird.

fsync-Funktion: in der UNIX-System-Header-Datei #include enthalten, wird verwendet, um alle geänderten Dateidaten im Speicher mit dem Speichergerät zu synchronisieren.

Beim Schreiben muss auch der Cache des Betriebssystem-Kernelraums durchlaufen werden. Der Redo-Log-Schreibvorgang ist in der folgenden Abbildung dargestellt.

Redo-Log-Flushing-Prozess

Binärprotokoll (Binlog)

Binärprotokoll Binlog ist ein Service-Layer-Protokoll und wird auch als Archivprotokoll bezeichnet. Binlog zeichnet alle Aktualisierungsvorgänge in der Datenbank auf, einschließlich Datenbankänderungen. Alle Vorgänge mit Datenänderungen müssen im Binärprotokoll aufgezeichnet werden. Daher kann Binlog problemlos Daten kopieren und sichern und wird daher häufig zur Synchronisierung von Master-Slave-Bibliotheken verwendet. Obwohl die Speicherinhalte von Binlog und Redo-Log ähnlich aussehen, unterscheiden sie sich tatsächlich. Das Redo-Protokoll ist ein physisches Protokoll, das die tatsächlichen Änderungen an bestimmten Daten aufzeichnet, während das Binlog ein logisches Protokoll ist, das die ursprüngliche Logik der SQL-Anweisung aufzeichnet, z. B. „Geben Sie ein Feld der Zeile mit der ID=2 an.“ 1" hinzufügen. Der Inhalt des Binlog-Protokolls ist binär. Abhängig von den Protokollformatparametern kann er auf SQL-Anweisungen, den Daten selbst oder einer Mischung aus beidem basieren. Im Allgemeinen werden häufig verwendete Datensätze SQL-Anweisungen verwendet.

Mein persönliches Verständnis der Konzepte von Physik und Logik ist hier:

Das physische Protokoll kann als Änderungsinformation auf der Datenseite in der tatsächlichen Datenbank betrachtet werden. Es wertet nur die Ergebnisse aus und kümmert sich nicht darum „Auf welche Weise“ wird dieses Ergebnis erzielt?

Logische Protokolle können als durch eine bestimmte Methode oder Operation verursachte Datenänderungen angesehen werden, und logische Operationen werden gespeichert.

Gleichzeitig basiert das Redo-Log auf der Wiederherstellung nach einem Absturz, um die Datenwiederherstellung nach einem MySQL-Absturz sicherzustellen, während Binlog auf einer zeitpunktbezogenen Wiederherstellung basiert, um sicherzustellen, dass der Server Daten basierend auf Zeitpunkten wiederherstellen oder Daten sichern kann .

Tatsächlich hatte MySQL zunächst kein Redo-Log. Da MySQL zunächst keine InnoDB-Engine hatte, war die integrierte Engine MyISAM. Binlog ist ein Service-Layer-Protokoll und kann daher von allen Engines verwendet werden. Binlog-Protokolle allein können jedoch nur Archivierungsfunktionen und keine absturzsicheren Funktionen bereitstellen. Daher verwendet die InnoDB-Engine eine von Oracle erlernte Technologie, nämlich das Redo-Protokoll, um absturzsichere Funktionen zu erreichen. Hier werden jeweils die Eigenschaften von Redo-Log und Binlog verglichen:

Vergleich der Eigenschaften von Redo-Log und Binlog

Wenn MySQL Aktualisierungsanweisungen ausführt, sind das Lesen und Schreiben von Redo-Log und Binlog-Protokoll beteiligt. Der Ausführungsprozess einer Update-Anweisung ist wie folgt:

Der Ausführungsprozess der MySQL-Update-Anweisung

Wie aus der obigen Abbildung ersichtlich ist, analysiert MySQL beim Ausführen der Update-Anweisung die Anweisung im Dienst und führt sie aus Gleichzeitig wird auf der Engine-Ebene das Binlog und in der InnoDB das Redo-Log geschrieben.

Darüber hinaus gibt es beim Schreiben des Redo-Logs zwei Phasen der Übermittlung: Zum einen wird der Vorbereitungsstatus geschrieben, bevor das Binlog geschrieben wird, und zum anderen wird der Commit-Status geschrieben, nachdem das Binlog geschrieben wird.

Der Grund für die Anordnung einer solchen zweistufigen Einreichung ist natürlich sinnvoll. Jetzt können wir davon ausgehen, dass wir anstelle der zweistufigen Übermittlung eine „einstufige“ Übermittlung übernehmen, d. h. entweder zuerst das Redo-Protokoll schreiben und dann das Binlog schreiben oder zuerst das Binlog und dann das Redo-Protokoll schreiben. Die Übermittlung auf diese beiden Arten führt dazu, dass der Status der Originaldatenbank nicht mit dem Status der wiederhergestellten Datenbank übereinstimmt.

Schreiben Sie zuerst das Redo-Protokoll und dann das Binlog:

Nach dem Schreiben des Redo-Protokolls sind die Daten zu diesem Zeitpunkt absturzsicher, sodass das System abstürzt und die Daten in den Zustand vor Beginn der Transaktion zurückversetzt werden. Wenn das System abstürzt, nachdem das Redo-Log geschrieben wurde, aber bevor das Binlog geschrieben wurde, dann... Zu diesem Zeitpunkt speichert binlog die obige Aktualisierungsanweisung nicht, was dazu führt, dass die obige Aktualisierungsanweisung fehlt, wenn binlog zum Sichern oder Wiederherstellen der Datenbank verwendet wird. Infolgedessen werden die Daten in der Zeile id=2 nicht aktualisiert. Das Problem besteht darin, zuerst das Redo-Protokoll und dann das Binlog zu schreiben Die Zeilen-ID=2 in der Datenbank wird auf a=1 aktualisiert. Wenn das System jedoch abstürzt, bevor das Redo-Protokoll geschrieben wird, ist die im Redo-Protokoll aufgezeichnete Transaktion ungültig, was dazu führt, dass die Daten in der Zeile id=2 in der tatsächlichen Datenbank nicht aktualisiert werden.

Das Problem besteht darin, zuerst Binlog und dann Redo-Log zu schreiben

Es ist ersichtlich, dass die zweistufige Übermittlung dazu dient, die oben genannten Probleme zu vermeiden und die im Binlog und Redo-Log gespeicherten Informationen konsistent zu machen.

Rollback-Protokoll (Rückgängig-Protokoll)

Die InnoDB-Engine stellt ein Rollback-Protokoll bereit, das für Daten-Rollback-Vorgänge verwendet wird. Wenn eine Transaktion die Datenbank ändert, zeichnet die InnoDB-Engine nicht nur das Redo-Protokoll auf, sondern generiert auch das entsprechende Rückgängig-Protokoll, wenn die Transaktionsausführung fehlschlägt oder ein Rollback aufgerufen wird, wodurch die Transaktion zurückgesetzt wird, die Informationen im Rückgängig-Protokoll kann verwendet werden, um die Daten wiederherzustellen, wie sie vor der Änderung aussahen.

Aber das Undo-Log unterscheidet sich vom Redo-Log. Es ist ein logisches Log. Es zeichnet Informationen im Zusammenhang mit der Ausführung von SQL-Anweisungen auf. Wenn ein Rollback auftritt, führt die InnoDB-Engine basierend auf den Datensätzen im Rückgängig-Protokoll das Gegenteil der vorherigen Arbeit aus. Beispielsweise wird für jeden Dateneinfügungsvorgang (Einfügen) ein Datenlöschvorgang (Löschen) während des Rollbacks ausgeführt Update-Vorgang (Update): Beim Rollback wird ein umgekehrter Datenaktualisierungsvorgang (Update) durchgeführt, um die Daten wieder zu ändern. Das Rückgängig-Protokoll hat zwei Funktionen: Eine besteht darin, ein Rollback bereitzustellen, und die andere darin, MVCC zu implementieren.

3.

Master-Slave-Replikation

Das Konzept der Master-Slave-Replikation besteht darin, eine identische Datenbank aus der Originaldatenbank zu kopieren und die kopierte Datenbank zu kopieren die Slave-Datenbank. Die Slave-Datenbank synchronisiert die Daten mit der Master-Datenbank, um die Datenkonsistenz zwischen beiden aufrechtzuerhalten.

Das Prinzip der Master-Slave-Replikation wird tatsächlich durch das Bin-Protokoll implementiert. Das Bin-Log-Protokoll speichert alle SQL-Anweisungen in der Datenbank. Durch Kopieren der SQL-Anweisungen im Bin-Log-Protokoll und anschließendes Ausführen der Anweisungen können die Slave-Datenbank und die Master-Datenbank synchronisiert werden.

Der Master-Slave-Replikationsprozess ist in der folgenden Abbildung dargestellt. Der Master-Slave-Replikationsprozess wird hauptsächlich von drei Threads ausgeführt. Ein sendender Thread läuft auf dem Master-Server und wird zum Senden von Binlog-Protokollen an den Slave-Server verwendet. Auf dem Slave-Server laufen zwei zusätzliche I/O-Threads und SQL-Threads. Der E/A-Thread wird verwendet, um den vom Hauptserver gesendeten Binlog-Protokollinhalt zu lesen und ihn in das lokale Relay-Protokoll zu kopieren. Der SQL-Thread liest SQL-Anweisungen mit Datenaktualisierungen aus dem Relay-Protokoll und führt auf der Grundlage dieser Anweisungen Vorgänge aus, um sicherzustellen, dass die Daten in der Master-Slave-Datenbank konsistent bleiben.

Master-Slave-Replikationsprinzip

Der Grund, warum eine Master-Slave-Replikation implementiert werden muss, hängt tatsächlich vom tatsächlichen Anwendungsszenario ab. Die Vorteile, die die Master-Slave-Replikation mit sich bringen kann, sind:

1. Realisieren Sie eine externe Datensicherung durch Replikation. Wenn die Master-Datenbank ausfällt, kann die Slave-Datenbank gewechselt werden, um Datenverluste zu vermeiden.

2. Wenn das Geschäftsvolumen größer wird und die E/A-Zugriffsfrequenz zu hoch ist, kann die Verwendung von Multi-Datenbank-Speicher die Häufigkeit des Festplatten-E/A-Zugriffs verringern und die E/A verbessern einer einzelnen Maschine.

3. Es kann die Trennung von Lesen und Schreiben realisieren, sodass die Datenbank eine größere Parallelität unterstützen kann.

4. Implementieren Sie einen Server-Lastausgleich, indem Sie die Last der Kundenanfragen zwischen dem Master-Server und dem Slave-Server aufteilen.

Das obige ist der detaillierte Inhalt vonWas sind die Merkmale des MySQL-Transaktionsprotokolls?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!