Eine umfassende Anleitung zu MySQL-Protokollen

Dieser Artikel vermittelt Ihnen relevantes Wissen über MySQL, das hauptsächlich auf Probleme im Zusammenhang mit Protokollen eingeht. Das Protokollsystem von MySQL ist der Schlüssel, um sicherzustellen, dass Daten nicht verloren gehen, egal, ob MySQL abstürzt. Ich hoffe, es hilft allen.

Empfohlene Lerninhalte: MySQL-Video-Tutorial

Das Protokollierungssystem von MySQL ist der Schlüssel zu MySQL und stellt sicher, dass keine Daten verloren gehen, egal wenn es abstürzt.

Wie wir alle wissen, ist MySQL eine persistente Datenbank und so weiter Die Daten bleiben auf der Festplatte gespeichert und stellen sicher, dass die Daten nicht verloren gehen. MySQL garantiert, dass die Daten nicht verloren gehen, und zwar aus den folgenden zwei Aspekten: Es kann den Datenstatus jederzeit wiederherstellen. Nein Angelegenheit vor oder nach der Übermittlung der Transaktion. Nach einem Absturz gehen die Daten nicht verloren Nicht verloren gehen

Der Schlüssel zu MySQL, der die beiden oben genannten Punkte garantiert, besteht darin, das Rückgängig-Protokoll, das Redo-Protokoll und das Binlog durch drei Protokolle zu implementieren Rollback-Protokoll von MySQL, das die alte Datenversion speichert Version vor Beginn der Transaktion, wenn die Transaktionsausführung fehlschlägt

• Welche Arten von Rückgängig-Protokollen gibt es?

• Undo-Protokolle haben zwei Arten

Für den Einfügebefehl zeichnet das Rückgängig-Protokoll den Primärschlüssel des neu hinzugefügten Datensatzes auf. Während des Rollbacks können Sie den entsprechenden Datensatz entsprechend dem Primärschlüssel im Rückgängig-Protokoll löschen

Für den Befehl „Aktualisieren/Löschen“ zeichnet das Rückgängig-Protokoll die alten Daten des geänderten Datensatzes auf

Jede Datenzeile in MySQL hat zwei Felder: die Transaktion ID der zuletzt geänderten aktuellen Datenzeile und der Rollback-Zeiger. Wenn die Datenzeile geändert wird. Danach zeigt der Rückgängig-Protokollzeiger auf die alte Datenzeile und der Rollback-Zeiger der neu generierten Datenzeile alte Datenzeile, auf die derzeit der Undo-Log-Zeiger zeigt

Mysql, um zu verhindern, dass der Undo-Log-Zeiger den Zeiger ändert. Wenn Parallelitätsprobleme auftreten, wird dem Undo-Log-Zeiger vor der Änderung eine exklusive Sperre hinzugefügt, um das korrekte Schreiben sicherzustellen des Rückgängig-Protokolls

Rückgängig-Protokoll Wann gelöscht werden soll

Undo-Protokoll wird verwendet, um sicherzustellen, dass die Transaktion abgeschlossen ist. Wenn sie nicht übermittelt wird, kann sie reibungslos auf den Zustand vor der Transaktion zurückgesetzt werden Wenn die Transaktion gestartet wird, verliert das Rückgängig-Protokoll seine Funktion und muss vom Purage-Thread gelöscht werden. Überprüfen Sie das Flag „Deleted_Bit“. auf „true“ gesetzt werden, nachdem die Transaktion festgeschrieben wurde. Wenn der Bereinigungsthread einen Datensatz findet, der wahr ist, ist er dafür verantwortlich, ihn zu löschen Anzahl der Vorgänge werden auf einer bestimmten Datenseite ausgeführt

Die Rolle des Redo-Logs

Verantwortlich für die Aufzeichnung der Datenänderung durch übermittelte Transaktionen. Der aufgezeichnete Inhalt ist wahrscheinlich der Z-Offset der Seite y der x-Tabelle An Es wurde ein Update durchgeführt

, sodass MySQL beim Senden einer Transaktion nicht auf die Datenpersistenzfestplatte warten muss und nur das Redo-Protokoll auf der Festplatte beibehalten muss

• Die Anzahl der nicht gelöschten Redo-Protokolle zeigt an, dass die Die Festplatte wurde nicht geleert. Die Anzahl der schmutzigen Seiten.

Warum entscheiden Sie sich dafür, das Redo-Protokoll bei der Übermittlung einer Transaktion beizubehalten, anstatt Daten auf der Festplatte beizubehalten? Das Beibehalten von Daten auf der Festplatte ist ein zufälliger E/A-Prozess, daher entscheidet sich MySQL dafür, das zwischenzuspeichern Daten und warten Sie auf eine geeignete Gelegenheit. Schreiben Sie Daten sofort auf die Festplatte, um IO zu reduzieren

Es besteht jedoch die Gefahr eines Daten-Cache-Verlusts im Speicher, daher entscheidet sich MySQL für die Beibehaltung des Redo-Protokolls

Das Redo-Protokoll wird sequentiell geschrieben, und die Effizienz von Die Persistenz ist höher als beim zufälligen Schreiben und das Redo-Log zeichnet die Änderungen in den Daten auf. Solange das Redo-Log vorhanden ist, können die Daten nach dem Neustart von MySQL wiederhergestellt werden. In InnoDB ist das Redo-Log ein fester Wert. Die Größe einer kreisförmigen warteschlangenähnlichen Existenz, und jeder Schreibvorgang erfolgt von hinten. Die Position der Schreibposition. Wenn Daten beibehalten werden, wird der Prüfpunkt zum Vorwärtslesen verschoben

Der Grund für dieses Design ist, dass das Redo-Protokoll vorhanden ist, um dies zu verhindern Die zwischengespeicherten Dirty-Page-Daten gehen nach einem Absturz von MySQL nicht verloren Unterschied zwischen Undo-Log und Redo-Log

Undo-Log zeichnet den Status alter Daten während der Transaktionsausführung auf, und Redo-Log zeichnet den Status nach der Datenaktualisierung auf.

Redo-Log garantiert tatsächlich die Haltbarkeit und Konsistenz von Transaktionen, während Undo-Log die Atomizität von Transaktionen garantiert. Funktionen

Binlog-Archivprotokoll

binlog ist ein von der MySQL-Serverschicht implementiertes Protokoll.

Funktion

binlog zeichnet die ursprüngliche Anweisungslogik von MySQL auf und kann daher aufgezeichnet werden Wird verwendet, um den Datenbankdatenstatus von MySQL jederzeit wiederherzustellen

Daher wird Binlog als Archivprotokoll bezeichnet. Gleichzeitig ist Binlog auch eine Abhängigkeit von MySQL, um die Master-Slave-Replikation zu implementieren. Die Slave-Bibliothek synchronisiert die Hauptbibliothek Durch Kopieren der Binlog-Wiedergabe aus der Hauptbibliothek wird zuerst das Protokoll auf die Festplatte geschrieben und dann werden die Daten nicht auf die Festplatte geschrieben sofort, aber das Protokoll wird zuerst geschrieben, um sicherzustellen, dass sowohl Redo-Protokoll als auch Binlog auf der Festplatte gespeichert sind, und dann wählt der Hintergrundthread den Zeitpunkt aus, zu dem die Daten auf der Festplatte gespeichert werden.

Warum müssen wir das Protokoll schreiben? Zuerst die Festplatte

Da das Löschen schmutziger Seiten ein zufälliger Lese- und Schreibvorgang ist, ist die Geschwindigkeit auf der Festplatte definitiv nicht so hoch wie bei Binlog. Daher entscheide ich mich, zuerst die Daten im Speicher zu ändern Wählen Sie die Möglichkeit, sie zu einem späteren Zeitpunkt asynchron auf der Festplatte zu speichern

Bevor die fehlerhaften Seiten auf die Festplatte geschrieben werden, stellt Redo Log | die Persistenz der Daten sicher und verhindert Datenverlust im Speicher bei Stromausfällen und startet neu. Wenn die schmutzigen Seiten voll sind, müssen sie auf die Festplatte geschrieben und dann gelöscht werden. Entfernen Sie sie dann und stellen Sie sie bei der nächsten Verwendung über das Redo-Protokoll wieder her Leistung: Wenn Daten jedes Mal, wenn sie von der Festplatte in den Speicher gelesen werden, mit dem Redo-Protokoll verglichen und aktualisiert werden müssen, ist die Effizienz sehr gering.

MySQL-Pinsel Das Schreiben schmutziger Seiten auf die Festplatte stellt sicher, dass die Datenseite so lange wie möglich ist Im Speicher können die neuesten Daten zurückgegeben werden, indem Sie sie auf jeden Fall von der Festplatte lesen, ohne erneut zur gleichen Seite gehen zu müssen Der Schreibprozess von Binlog und Redo-Log ist die grundlegende Garantie des WAL-Mechanismus. Sowohl Binlog als auch Redo-Log unterteilen das Schreiben von Protokollen in drei Prozesse: Cache schreiben, schreiben und synchronisieren. Während der Transaktionsausführung werden Binlog und Redo-Log während des Prozesses ausgeführt In den entsprechenden zugewiesenen Cache geschrieben, sodass sie beim Senden der Transaktion gleichzeitig auf die Festplatte geschrieben werden können. Beim Senden der Transaktion werden die Daten zuerst auf die Betriebssystemseite geschrieben. Die Daten wurden zu diesem Zeitpunkt noch nicht in die Datei geschrieben, sie wurden jedoch zur sicheren Aufbewahrung an den Cache des Betriebssystems übergeben. Wenn der MySQL-Prozess zu diesem Zeitpunkt abstürzt, geht dieser Teil der geschriebenen Daten nicht verloren. und der Kernel-Thread des Betriebssystems ist dafür verantwortlich, diesen Teil der Daten im Cache auf die Festplatte zu schreiben

Wenn das Betriebssystem jedoch abstürzt, geht dieser Teil der Daten verloren

Endlich MySQL ruft sync manuell auf, um die in den Seitencache geschriebenen Daten auf der Festplatte beizubehalten. Nach Abschluss des Schreibvorgangs werden die Daten erfolgreich beibehalten. Die letzten Schreib- und Synchronisierungsschritte von MySQL stellen entsprechende Parameter zur Steuerung der Schreibstrategie bereit Das Protokoll wird von innodb_flush_log_at_trx_commit gesteuert. Wenn es auf 0 gesetzt ist, bedeutet dies, dass das Redo-Protokoll bei jeder Übermittlung nur im Redo-Log-Cache verbleibt bedeutet, dass jedes Mal, wenn eine Transaktion übermittelt wird, das Redo-Protokoll direkt auf der Festplatte gespeichert wird. Das Verlustrisiko ist minimal, aber die E/A-Nutzung ist groß Wird übermittelt, wird das Redo-Protokoll nur in den Seitencache geschrieben

Die E/A-Nutzung wird zentriert und der Schreibvorgang wird dem Betriebssystem überlassen. Das Binlog wird durch den Parameter gesteuert sync_binlog=0 bedeutet, dass bei jeder Übermittlung einer Transaktion nur Schreibvorgänge ausgeführt werden, nicht fsync.

sync_binlog=Bei 1 bedeutet dies, dass fsync bei jeder Übermittlung einer Transaktion ausgeführt wird =N(N>1), das bedeutet, dass der Schreibvorgang jedes Mal durchgeführt wird, wenn eine Transaktion übermittelt wird, aber fsync wird ausgeführt, nachdem N Transaktionen akkumuliert wurden.

Was ist eine zweistufige Protokollübermittlung?

Der Prozess der Redo-Log-Übermittlung ist in zwei Phasen unterteilt: Vorbereiten und Festschreiben. Die Binlog-Log-Übermittlung befindet sich in der Mitte dieser beiden Phasen.

Wenn eine Transaktion übermittelt wird, steht das Redo-Protokoll an erster Stelle Nachdem die Binlog-Übermittlung abgeschlossen ist, kann das Redo-Protokoll den Status des übermittelten Protokolls ändern

Warum eine zweistufige Protokollübermittlung erforderlich ist? Dies hängt mit dem Rollback-Mechanismus der InnoDB-Engine zusammen wurde übermittelt Die Transaktion kann nicht zurückgesetzt werden, nachdem das Redo-Protokoll gesendet wurde. Es kommt zu zwei Inkonsistenzen. Wenn die Datenbank zu diesem Zeitpunkt abnormal neu startet, lohnt es sich, darüber nachzudenken, welche zum Wiederherstellen verwendet werden soll Daten, daher sind nur zwei Phasen der Protokollübermittlung erforderlich

Angenommen, die Datenbank stürzt zum Zeitpunkt A ab, weil das Binlog nicht geschrieben und das Redo-Protokoll nicht übermittelt wurde, sodass die Transaktion nach dem Neustart zurückgesetzt wird und die beiden Protokolle immer noch im gleichen Zustand sind Es ist Zeitspanne B, Sie müssen es korrigieren. Überprüfen Sie, ob ein Commit-Flag im Redo-Log vorhanden ist. Wenn dort ein Commit-Flag vorhanden ist Ist kein Commit-Flag der entsprechenden Transaktion im Redo-Log, wird das Binlog überprüft

Wenn das Binlog vollständig ist und das Commit-Flag hat, wird die Transaktion übermittelt und das Commit-Flag wird nach dem Redo-Log hinzugefügt . Wenn das Binlog unvollständig ist, wird die Transaktion zurückgesetzt
Hier können Sie feststellen, dass während der zweistufigen Protokollübermittlung ein Absturz aufgetreten ist. Der Grund dafür ist, dass die Master-Slave-Replikation erfolgt Basierend auf Binlog. Wenn die Integrität beider Protokolle überprüft werden muss, wird die Zeit für den Wechsel zur Slave-Bibliothek länger, nachdem die Master-Bibliothek aufgelegt hat. Als Benchmark: Wenn die Hauptdatenbank ausgefallen ist, verwenden Sie einfach das Binlog Stellen Sie die Daten aus der Slave-Datenbank wieder her. Es ist nicht erforderlich, die Integrität des Redo-Protokolls zu überprüfen. Darüber hinaus ist Binlog ein gemeinsames Protokoll für die MySQL-Server-Ebene, weshalb Binlog auch als Benchmark ausgewählt wurde
• Zwei Nachteile der Übermittlung von Bühnenprotokollen

Hohe Festplatten-IO-Zeiten

Bei der Übermittlung von Protokollen kommt es zu Flush-Vorgängen, die dem Redo-Log und dem Binlog entsprechen. Die Anzahl der IOs ist hoch.

Heftiger Wettbewerb um Sperren

• Um sicherzustellen, dass bei der Übermittlung mehrerer Transaktionen die Protokolldatensätze mit der Reihenfolge der Transaktionsübermittlung übereinstimmen, werden Sperren verwendet, um die relative Reihenfolge der Protokollübermittlungen sicherzustellen.

Aber die Leistung verschlechtert sich, wenn der Grad der Parallelität zunimmt groß

Gruppenübermittlungsmechanismus

Die Rolle des Gruppenübermittlungsmechanismus

Wenn es eine Transaktion gibt, die der Übermittlung entgangen ist, werden Protokolle mehrerer Transaktionen zum Schreiben zusammengeführt, wodurch Festplatten-E/A-Vorgänge reduziert werden

Implementierung des Gruppenübermittlungsmechanismus Der Gruppenübermittlungsmechanismus teilt den Commit-Prozess in drei Prozesse auf, unterhält eine Warteschlange für jeden Prozess und verwendet Sperren, um die Schreibreihenfolge von Transaktionen sicherzustellen.

Die Aufteilung von Sperren in drei Stufen kann die Reduzierung reduzieren Granularität sperren, ohne den gesamten Übermittlungsprozess der Transaktion zu sperren : Flush-Phase: Mehrere Transaktionen schreiben das Binlog in der Reihenfolge des Eintrags aus dem Cache in die Datei (ohne die Festplatte zu leeren)

Die erste Transaktion, die in die Flush-Phase eintritt, dient als Anführer die nachfolgenden Transaktionen

Führung Die Transaktion führt dazu, dass alle Transaktionen in das Redo-Log schreiben + fsyncen, das heißt, das Redo-Log auf die Festplatte schreiben und die Vorschlagsphase des Redo-Logs abschließenWenn MySQL zu diesem Zeitpunkt abstürzt, ist dies der Fall Satz von Transaktionen wird nach dem Neustart zurückgesetzt

Phase 2: sync: Fsync-Vorgang für die Binlog-Datei ausführen (die Binlogs mehrerer Transaktionen zusammenführen und die Festplatte zusammen leeren)

Nach dem Schreiben des Binlogs in Die Binlog-Datei befindet sich in der Flush-Phase und wartet eine gewisse Zeit. Anschließend wird die Festplatte geleert. Der Zweck besteht darin, das Binlog mehrerer Transaktionen zu kombinieren und die Festplatte zusammen zu leeren, um den Verbrauch zu reduzieren

• Es wird ein Zeitlimit und eine maximale Transaktion geben Wartelimit. Wenn eine der Bedingungen erfüllt ist, wird das Binlog sofort geleert

Die Synchronisierungsphase ist hauptsächlich für die Übermittlung der Binlog-Gruppe verantwortlich. Wenn MySQL in der aktuellen Phase abstürzt, können Sie die Transaktionsübermittlung über fortsetzen Redo-Log-Flush-Datensatz nach dem Neustart

Da das Binlog zu diesem Zeitpunkt die Übermittlung abgeschlossen hat, können Sie die Transaktion gemäß dem Redo-Log weiter übermittelnflush阶段 : 多个事务按进入的顺序将binlog从cache中写入文件 (不刷盘)

第一个进入flush阶段的事务会作为领导者领导后面进入的事务

领导者事务会带领所有的事务对 redo log 进行一次 write + fsync, 也就是将redo log 写入磁盘, 完成redo log 的propare阶段

如果在这个阶段Mysql崩溃了, 会在重启后回滚这组事务

阶段二 : sync : 对binlog文件做fsync操作 (将多个事务的binlog合并一起刷盘)

在flush阶段将binlog写入到binlog文件后, 会等待一段时间再进行刷盘, 目的是组合更多事务的binlog一起刷盘减少消耗

等待会有时间限制和最大事务限制, 满足其中一个条件就会立刻对binlog进行刷盘

sync阶段主要负责binlog的组提交, 如果当前阶段Mysql崩溃的话, 在重启后可以通过redo log的刷盘记录继续完成事务提交

• 因为此时binlog已经完成提交了, 所以可以根据redo log来继续提交事务

阶段三 : commit

Stufe 3: commit: Führen Sie InnoDB aus Commit-Vorgang für jede Transaktion

Empfohlenes Lernen: 🎜MySQL-Video-Tutorial🎜🎜

Das obige ist der detaillierte Inhalt vonEine umfassende Anleitung zu MySQL-Protokollen. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!