Einführung in die drei wesentlichen Protokolle für MySQL-Datenbankinterviews

Beginnen wir schnell mit der Überlegung einer Frage: Wie stellt MySQL sicher, dass keine Daten verloren gehen?

Um sicherzustellen, dass keine Daten verloren gehen, sind die folgenden beiden Funktionen erforderlich:
(1) Möglichkeit zur jederzeitigen Wiederherstellung des alten Zustandes;
(2) Es kann sichergestellt werden, dass die übermittelten Daten nicht verloren gehen, wenn MySQL plötzlich abstürzt und jederzeit neu gestartet wird, und dass die unvollständigen Daten automatisch zurückgesetzt werden.

Bringt uns das nicht zu dem Thema, über das wir heute sprechen werden? Um den ersten Punkt zu erreichen, müssen wir das Binärprotokoll verwenden, und um den zweiten Punkt zu erreichen, müssen wir das Redo-Protokoll und das Undo-Protokoll verwenden.

Bevor wir uns mit den drei Hauptprotokollen befassen, werfen wir einen Blick auf den Prozess der MySQL-Datenaktualisierung:

Das obige Bild enthält die allgemeine Beziehung zwischen den drei Protokolltypen: Redo-Protokoll, Binärprotokoll und Undo-Protokoll. Kommen wir nun zum Punkt.

1. Redo-Log (Transaktionsprotokoll der MySQL-Speicher-Engine InnoDB)

Wir wissen, dass MySQL-Daten auf der Festplatte gespeichert werden und bei jedem Lesen oder Schreiben von Daten eine Festplatten-E/A erforderlich ist, was in gleichzeitigen Szenarien zu einer schlechten Leistung führt. Zu diesem Zweck führt MySQL zur Optimierung den Cache- Pufferpool ein. Es enthält eine Zuordnung einiger Datenseiten auf der Festplatte, um die Festplattenlast der Datenbank zu verringern.

Beim Lesen von Daten aus der Datenbank werden diese zuerst aus dem Cache gelesen. Wenn sich die Daten nicht im Cache befinden, werden sie von der Festplatte gelesen und in den Cache gestellt. Beim Schreiben von Daten in die Datenbank werden diese zuerst in den Cache geschrieben. Zu diesem Zeitpunkt werden die Daten der Datenseite im Cache geändert. Diese Datenseite wird als „Dirty Page“ bezeichnet. Nachdem die Daten im Pufferpool geändert wurden, werden sie gemäß der festgelegten Strategie regelmäßig auf die Festplatte geleert. Dieser Vorgang wird als „Löschen von Dirty Pages“ bezeichnet.

Die Frage ist also: Wenn die geänderten Daten im Pufferpool nicht rechtzeitig auf die Festplatte geschrieben werden, stürzt MySQL ab und wird neu gestartet. Dies führt zu Datenverlust und die Persistenz der Transaktion kann nicht garantiert werden. Was sollen wir tun?

Redo-Log löst dieses Problem. Das heißt, wenn die Datenbank Daten ändert, schreibt sie zuerst den Aktualisierungsdatensatz in das Redo-Protokoll und ändert dann die Daten im Pufferpool. Wenn die Transaktion festgeschrieben ist, wird fsync aufgerufen, um das Redo-Protokoll auf die Festplatte zu spülen. Der Zeitpunkt, wann die aktualisierten Datendateien im Cache auf die Festplatte geschrieben werden, wird asynchron vom Hintergrund-Thread erledigt.

Hinweis : Zu diesem Zeitpunkt lautet der Status der Redo-Log-Transaktion „Vorbereiten“ und sie wurde noch nicht wirklich erfolgreich festgeschrieben. Sie wird erst dann auf „Festschreiben“ geändert, wenn das Binärprotokoll auf die Festplatte geschrieben wurde. Nur dann kann die Transaktion wirklich erfolgreich festgeschrieben werden.

Wie schreibe ich ein Redo-Log?

Das Redo-Protokoll wird kreisförmig mit einer festen Größe geschrieben. Wenn es voll ist, wird es kreisförmig von Anfang an erneut geschrieben, ähnlich einem Ring. Der Grund für dieses Design besteht darin, dass das Redo-Protokoll die Änderungen auf der Datenseite aufzeichnet. Wenn die Datenseite im Pufferpool auf die Festplatte geleert wurde, werden diese Datensätze ungültig und das neue Protokoll überschreibt und löscht diese ungültigen Datensätze.

Hinweis : Wenn das Redo-Protokoll voll ist, stellen Sie sicher, dass alle zu löschenden Datensätze vor dem Löschen auf die Festplatte geschrieben wurden. Während alte Datensätze gelöscht werden, um neuen Speicherplatz freizugeben, können keine neuen Aktualisierungsanforderungen empfangen werden und die MySQL-Leistung wird beeinträchtigt. Daher ist es wichtig, die Größe des Redo-Protokolls in Situationen mit hoher Parallelität richtig anzupassen.

Was ist Crashsicherheit?

Die Innodb-Engine verfügt über Absturzsicherungsfunktionen. Dies bedeutet, dass in jeder Phase des Transaktionsübermittlungsprozesses die Integrität der Transaktion gewährleistet werden kann, nachdem MySQL abstürzt und neu gestartet wird, und die übermittelten Daten nicht verloren gehen. Diese Funktion wird durch Redo-Logs gewährleistet. Wenn MySQL abstürzt und neu gestartet wird, überprüft das System automatisch die Redo-Logs und stellt die geänderten Daten, die noch nicht auf die Festplatte geschrieben wurden, aus den Redo-Logs in MySQL wieder her.

2. Undo-Log-Rollback-Log (Transaktionsprotokoll der MySQL-Speicher-Engine InnoDB)

Das Undo-Protokoll zeichnet den Status vor der Änderung der Daten auf. Es gehört zum logischen Protokoll und übernimmt die Rolle des Rollbacks. Es ist der Schlüssel zur Gewährleistung der Atomizität von Transaktionen.
Wenn beispielsweise das Namensfeld des Datensatzes mit der ID=1 aktualisiert wird, lautet der ursprüngliche Name Xiao Wang und wird nun in Xiao Zhang geändert. Wenn die Transaktion die Anweisung update X set name = Xiao Zhang where id = 1 ausführt, wird zuerst ein Datensatz update X set name = Xiao Wang where id = 1 mit der entgegengesetzten Logik im Undo-Protokoll aufgezeichnet. Auf diese Weise kann das Undo-Protokoll verwendet werden, um die Daten auf den Zustand vor der Ausführung der Transaktion zurückzusetzen, wenn die Transaktion aus irgendeinem Grund fehlschlägt.

Die Frage ist also: Wenn ein Datensatz derselben Transaktion mehrere Male geändert wird, müssen wir dann jedes Mal das Undo-Protokoll des Status vor der Datenänderung schreiben?

Nein, da das Undo-Log nur die Originalversion der Daten vor Beginn der Transaktion aufzeichnet. Wenn diese Datenzeile erneut geändert wird, wird der generierte Änderungsdatensatz in das Redo-Log geschrieben. Das Undo-Protokoll ist für das Rollback und das Redo-Protokoll für das Rollforward zuständig.

Was ist Rollback und Rollforward?

(1) Rollback

Nicht festgeschriebene Transaktionen, d. h. Transaktionen, die nicht festgeschrieben wurden. Allerdings wurden einige der innerhalb der Transaktion geänderten schmutzigen Seiten auf die Festplatte geschrieben. Zu diesem Zeitpunkt stürzt die Datenbank ab und wird neu gestartet. Außerdem ist ein Rollback erforderlich, um die fehlerhaften Blöcke zu entfernen, die von der Festplatte gelöscht wurden.

(2) Vorwärtsrollen

Eine unvollständig festgeschriebene Transaktion bedeutet, dass die Transaktion festgeschrieben wurde, aber nur ein Teil der Daten in den in der Transaktion geänderten schmutzigen Seiten auf die Festplatte geschrieben wurde und der andere Teil sich noch im Pufferpool befindet. Zu diesem Zeitpunkt, wenn die Datenbank abstürzt und neu gestartet wird, wird Rollforward verwendet, um die Daten, die nicht auf die Festplatte geschrieben wurden, aus dem Redo-Protokoll wiederherzustellen und auf die Festplatte zu schreiben.

3. Binärprotokoll-Archivprotokoll (binäres logisches Protokoll auf Datenbankserverebene, unabhängig von der Engine)

Das Binärprotokoll zeichnet alle von Benutzern an der Datenbank ausgeführten SQL-Vorgänge auf (ausgenommen Abfrageanweisungen, da solche Vorgänge die Daten selbst nicht ändern). Der Grund für die Bezeichnung Archivprotokoll liegt darin, dass es im Gegensatz zu einem Redo-Protokoll nicht zyklisch vorherige Aufzeichnungen löscht, sondern immer weiter protokolliert. Die standardmäßige maximale Kapazität einer Binärprotokolldatei beträgt 1 GB (kann mit dem Parameter max_binlog_size geändert werden). Wenn ein einzelnes Protokoll den Maximalwert überschreitet, wird eine neue Datei erstellt, um mit dem Schreiben fortzufahren.
Hinweis : Protokolle können basierend auf Transaktionen aufgezeichnet werden, und Transaktionen sollten nicht dateiübergreifend aufgezeichnet werden. Wenn die Binlog-Protokolldatei den Maximalwert erreicht, die Transaktion jedoch nicht festgeschrieben wurde, wird kein neuer Dateidatensatz erstellt, aber das Protokoll wächst weiter. Daher entspricht der Wert von max_binlog_size nicht unbedingt der tatsächlichen Größe der Binlog-Datei.

Nach der obigen Einführung wird Binlog hauptsächlich für die Master-Slave-Synchronisierung und die zeitpunktbasierte Datenbankwiederherstellung verwendet.

Die Frage ist also, können wir auf Binlog verzichten (warum brauchen wir Binlog, wenn wir ein Redo-Log haben)?

Muss mir die Szene ansehen:

Im Master-Slave-Modus ist Binlog erforderlich, da die Datensynchronisierung der Slave-Datenbank von Binlog abhängt.

Wenn im Standalonemodus keine zeitpunktbezogene Wiederherstellung der Datenbank in Betracht gezogen wird, ist Binlog nicht erforderlich, da Redo Log eine Absturzsicherheit gewährleisten kann.

Nachdem die Redo-Log-Datensätze geändert und auf die Festplatte geschrieben wurden, wird das Protokoll überschrieben und kann nicht für Vorgänge wie die Datenwiederherstellung verwendet werden. Das Redo-Log wird auf der InnoDB-Engine-Ebene implementiert und ist nicht in allen Engines vorhanden.

Was ist der Unterschied zwischen Redo-Log und Bin-Log?

Was ist ein Redo-Log-Zweiphasen-Commit und warum führen wir es durch?
Nachdem der Speicher aktualisiert wurde, schreibt die Engine-Ebene das Redo-Protokoll und ändert den Status, um das Commit der ersten Phase vorzubereiten. Die Server-Ebene schreibt das Bin-Protokoll und ändert den Status auf „Commit“, um das Commit der zweiten Phase durchzuführen. Der Zweck des zweiphasigen Commits besteht darin, die Konsistenz der Binlog- und Redo-Log-Daten sicherzustellen.

Was würde passieren, wenn es kein zweiphasiges Commit wäre?
1) Angenommen, zuerst wird das Redo-Protokoll und dann das Bin-Protokoll geschrieben. Das heißt, das Redo-Protokoll hat keine Vorbereitungsphase. Nach dem Schreiben wird es direkt auf Commit gesetzt und dann wird das Bin-Protokoll geschrieben. Wenn die Datenbank nach dem Schreiben des Redo-Protokolls, aber vor dem Schreiben des Bin-Protokolls abstürzt, verwendet das System nach dem Neustart automatisch das Redo-Protokoll zur Wiederherstellung. Zu diesem Zeitpunkt sind mehr Datenseitendaten auf der Festplatte vorhanden als die im Bin-Protokoll aufgezeichneten Daten, was zu inkonsistenten Daten führt.
2) Gehen Sie davon aus, dass zuerst das Binärprotokoll und dann das Redo-Protokoll geschrieben wird. Wenn die Datenbank abstürzt, nachdem das Binärprotokoll geschrieben wurde, aber nicht das Redo-Protokoll, sind die Datensätze im Binärprotokoll größer als die Datensätze in den Datenseiten auf der Festplatte. Wenn Sie das nächste Mal das Binärprotokoll zum Wiederherstellen von Daten verwenden, stimmen die wiederhergestellten Daten nicht mit den Originaldaten überein.

Beschreiben Sie den Notfallwiederherstellungsprozess des Redo-Logs.
Wenn das Redo-Protokoll vollständig ist (Commit), führen Sie die Wiederherstellung direkt mithilfe des Redo-Protokolls durch.
Wenn sich das Redo-Log im Vorbereitungszustand, aber nicht im Commit-Zustand befindet, müssen Sie feststellen, ob das Binärprotokoll vollständig ist. Wenn es vollständig (commited) ist, committen Sie das Redo-Log und verwenden Sie es dann zur Wiederherstellung. Wenn es unvollständig ist, führen Sie ein Rollback der Transaktion durch.

Dies ist das Ende dieses Artikels über die drei wesentlichen Protokolle für MySQL-Datenbankinterviews. Weitere Informationen zu den drei wichtigsten MySQL-Protokollen finden Sie in früheren Artikeln auf 123WORDPRESS.COM oder in den verwandten Artikeln weiter unten. Ich hoffe, Sie werden 123WORDPRESS.COM auch in Zukunft unterstützen!