So verwenden Sie das Binlog, Redo-Log und Undo-Log von MySQL

1. Binlog

Binlog wird zum Aufzeichnen von Informationen über in der Datenbank ausgeführte Schreibvorgänge verwendet. Es schließt Abfragevorgänge aus und wird im Binärformat auf der Festplatte gespeichert. Binlog ist das logische Protokoll von MySQL und wird von der Serverebene mit jeder Speicher-Engine aufgezeichnet, die Binlog-Protokolle aufzeichnet.

• Logisches Protokoll: kann einfach als SQL-Anweisung verstanden werden;

• Physisches Protokoll: Die Daten in MySQL werden auf der Datenseite gespeichert und das physische Protokoll zeichnet Änderungen auf der Datenseite auf

Binlog wird durch Anhängen geschrieben. Sie können die Größe jeder Binlog-Datei über den Parameter max_binlog_size festlegen. Wenn die Dateigröße den angegebenen Wert erreicht, wird eine neue Datei generiert, um das Protokoll zu speichern.

Binlog-Nutzungsszenarien
Projekt In praktischen Anwendungen gibt es zwei Hauptnutzungsszenarien von Binlog, nämlich Master-Slave-Replikation und Datenwiederherstellung.

• Master-Slave-Replikation: Aktivieren Sie das Binlog auf der Master-Seite und senden Sie das Binlog dann an jede Slave-Seite. Die Slave-Seite spielt das Binlog erneut ab, um eine Master-Slave-Datenkonsistenz zu erreichen.

• Datenwiederherstellung: Stellen Sie Daten mit dem mysqlbinlog-Tool wieder her. „MySQL-Master-Slave-Synchronisationsprinzip“ binlog. Bei Lesevorgängen im Binlog sperrt dieser Thread das Binlog auf dem Master-Knoten. Wenn der Lesevorgang abgeschlossen ist, wird die Sperre aufgehoben, noch bevor sie an den Slave-Knoten gesendet wird Wenn der Start-Slave-Befehl auf dem Slave-Knoten ausgeführt wird, erstellt der Slave-Knoten einen E/A-Thread, um eine Verbindung zum Master-Knoten herzustellen und das aktualisierte Binlog in der Master-Bibliothek anzufordern. Nachdem der E/A-Thread die Aktualisierung vom Master-Knoten-Binlog-Dump-Prozess erhalten hat, speichert er sie im lokalen Relaylog Spezifische Vorgänge und deren Ausführung.

  MySQL-Datenbank-Master-Slave-Synchronisationsprinzip

Inhalt von Binlog
Wie oben erwähnt, ist Binlog ein logisches Protokoll, das einfach als verstanden werden kann SQL-Anweisung, enthält aber tatsächlich auch die umgekehrte Logik der ausgeführten SQL-Anweisung. delete entspricht dem Löschen selbst und dem Reverse-Insert-Update. Es enthält Informationen zu den Datenzeilen vor und nach der Ausführung des entsprechenden Updates.

Binlog-Format

• Es gibt drei Binlog-Formate, nämlich Anweisung, Zeile und gemischt. Vor MySQL 5.7.7 wurde standardmäßig die Anweisung verwendet, und nach MySQL 5.7.7 wurde standardmäßig die Zeile verwendet. Das Format des Protokolls kann über binlog-format in der Konfigurationsdatei my.ini geändert werden.
  (1) Anweisung: Aussagebasierte Replikation (SBR), jede SQL-Anweisung, die Daten ändert, wird im Binlog aufgezeichnet.

• Vorteile: Änderungen in einer bestimmten Zeile müssen nicht speziell aufgezeichnet werden, was Platz spart, E/A reduziert und die Leistung verbessert;
  

• Nachteile: Beim Ausführen von Vorgängen wie sysdate() oder sleep() kann es zu Problemen kommen Inkonsistenz zwischen Master- und Slave-Datensituation;

  
  
  

  (2) Zeile: Zeilenbasierte Replikation (RBR), die keine kontextbezogenen Informationen der SQL-Anweisung aufzeichnet, sondern die Details darüber aufzeichnet, welcher Datensatz geändert wurde.

Vorteile: Die Details der Änderung jeder Datensatzzeile werden sehr detailliert aufgezeichnet, sodass es keine Situation gibt, in der die Daten nicht korrekt kopiert werden können.

Nachteile: Da die Details der Änderung jeder Zeile erfasst werden Da die Aufzeichnung sehr detailliert aufgezeichnet wird, wird dadurch eine Menge Protokollinhalt generiert. Gehen Sie davon aus, dass eine Aktualisierungsanweisung vorliegt und viele Datensätze geändert werden. Jeder geänderte Datensatz wird im Binlog aufgezeichnet. Insbesondere bei der Operation alter table ändert sich aufgrund von Änderungen in der Tabellenstruktur jede Datensatzzeile, was zu einem plötzlichen Anstieg des Protokollvolumens führt.

(3) gemischt: Gemäß der obigen Aussage und Jede Reihe hat ihre eigenen Vor- und Nachteile. Daher erschien die gemischte Version, die beide vermischt. Unter normalen Umständen wird zum Speichern das Anweisungsformat verwendet. Wenn die Anweisung nicht gelöst werden kann, wechseln Sie zum Speichern in das Zeilenformat.

• Binlog-Löschzeitpunkt

• Für die InnoDB-Speicher-Engine wird das Binlog nur aufgezeichnet, wenn die Transaktion übermittelt wird. Zu diesem Zeitpunkt befindet sich der Datensatz noch im Speicher, und zwar über sync_binlog Wertebereich ist 0-N:

  • 0: Nicht erzwungen auf die Festplatte, das System entscheidet, wann auf die Festplatte geschrieben wird.

  • 1: Binlog muss nach jeder Übermittlung auf die Festplatte geschrieben werden auf die Festplatte geschrieben;

  • Wie oben ersichtlich ist, ist die sicherste Einstellung für sync_binlog 1, was auch der Standardwert für MySQL-Versionen nach 5.7.7 ist. Das Festlegen eines größeren Werts kann jedoch die Datenbankleistung verbessern. Daher können Sie in tatsächlichen Situationen den Wert auch entsprechend erhöhen und einen gewissen Grad an Konsistenz opfern, um eine bessere Leistung zu erzielen.

  Die physische Dateigröße von Binlog

  Sie können die Größe von Binlog steuern, indem Sie den Parameter max_binlog_size konfigurieren, der sich in der Konfigurationsdatei my.ini befindet. Das System erstellt eine neue Datei, um weiterhin Protokolle zu speichern, wenn die Größe des Protokolls die Kapazitätsgrenze der Binlog-Datei überschreitet. Was soll ich tun, wenn eine Transaktion relativ groß ist oder immer mehr Protokolle vorhanden sind und der physische Speicherplatz, den sie einnimmt, zu groß ist? MySQL bietet einen automatischen Löschmechanismus, der durch Konfigurieren des Parameters „expire_logs_days“ in der Konfigurationsdatei „my.ini“ gelöst werden kann. Die Einheit ist Tage. Wenn dieser Parameter 0 ist, bedeutet dies, dass er nie gelöscht wird. Wenn er N ist, bedeutet dies, dass er nach dem N-ten Tag automatisch gelöscht wird. 2. Redo-Log

  redolog ist das proprietäre Protokollsystem der InnoDB-Engine. Es wird hauptsächlich verwendet, um Transaktionsdauerhaftigkeit und absturzsichere Funktionen zu erreichen. Redolog ist ein physisches Protokoll, das die spezifischen Änderungen auf der Datenseite aufzeichnet, nachdem die SQL-Anweisung ausgeführt wurde.

  Wir alle wissen, dass Daten von der Festplatte in den Speicher geladen werden, wenn MySQL ausgeführt wird. Wenn eine SQL-Anweisung zum Ändern der Daten ausgeführt wird, wird der geänderte Inhalt tatsächlich nur vorübergehend im Speicher gespeichert. Wenn zu diesem Zeitpunkt die Stromversorgung unterbrochen wird oder andere Umstände eintreten, gehen diese Änderungen verloren. Daher sucht MySQL nach der Änderung der Daten nach Möglichkeiten, diese Speicherdatensätze zurück auf die Festplatte zu schreiben. Es gibt jedoch ein Leistungsproblem, hauptsächlich in zwei Aspekten:
  InnoDB interagiert mit der Festplatte in Dateneinheiten von Seiten, und eine Transaktion ändert möglicherweise nur einige Bytes auf einer Seite, wenn ein Zurückspülen vollständiger Datenseiten auf die Festplatte erfolgt Verschwendung von Ressourcen;

  
  Eine Transaktion kann mehrere Datenseiten umfassen, die nur logisch, aber nicht physisch kontinuierlich sind. Daher ist die Leistung von MySQL zu gering, um die spezifischen Änderungen aufzuzeichnen die Datenseite durch die Transaktion und leeren Sie dann das Redolog zurück auf die Festplatte. Möglicherweise haben Sie Zweifel. Ursprünglich wollte ich io reduzieren. Würde dies nicht ein weiteres io hinzufügen? Die Designer von InnoDB haben diese zu Beginn des Entwurfs berücksichtigt. Redo-Log-Dateien sind normalerweise klein und beim Leeren der Festplatte wird sequenzielle E/A verwendet. Bessere Leistung im Vergleich zu zufälliger E/A.

  Grundkonzept des Redo-Logs
  Redolog besteht aus zwei Teilen: Einer ist der Redo-Log-Puffer im Speicher und der andere ist die Redo-Log-Datei auf der Festplatte. Jedes Mal, wenn der Datensatz geändert wird, werden diese Änderungen zuerst in den Redo-Log-Puffer geschrieben und dann auf die entsprechende Gelegenheit gewartet, um die Änderungen im Speicher zurück in die Redo-Log-Datei zu schreiben. Diese Technologie, bei der zuerst Protokolle geschrieben und dann auf die Festplatte geschrieben werden, ist die WAL-Technologie (Write-Ahead Logging). Es ist zu beachten, dass das Redolog vor der Datenseite auf die Festplatte zurückgeschrieben wird. Änderungen am Clustered-Index, am Sekundärindex und an der Rückgängig-Seite müssen alle im Redolog aufgezeichnet werden.
  In Computer-Betriebssystemen können Pufferdaten im Benutzerbereich im Allgemeinen nicht direkt auf die Festplatte geschrieben werden und müssen den Kernel-Speicherplatzpuffer (OS-Puffer) des Betriebssystems durchlaufen. Wenn Sie also den Redo-Log-Puffer in die Redo-Log-Datei schreiben, wird er tatsächlich zuerst in den Betriebssystempuffer geschrieben und dann über den Systemaufruf fsync () in die Redo-Log-Datei geleert. Der Prozess ist wie folgt:

  MySQL unterstützt drei Arten von Redo-Log-Puffer Der Zeitpunkt des Schreibens der Redo-Log-Datei kann über den Parameter innodb_flush_log_at_trx_commit konfiguriert werden. Die Bedeutung jedes Parameterwerts ist wie folgt:
  

  
  Parameterwert
  

  Bedeutung Das Redo wird nicht festgeschrieben, wenn die Transaktion übermittelt wird. Das Protokoll im Protokollpuffer wird in den Betriebssystempuffer geschrieben. Stattdessen wird das Protokoll jede Sekunde in den Betriebssystempuffer geschrieben und fsync() wird aufgerufen, um es zu schreiben die Redo-Log-Datei. Mit anderen Worten: Bei der Einstellung 0 werden (ungefähr) jede Sekunde Daten auf die Festplatte geschrieben. Bei einem Systemabsturz geht 1 Sekunde Daten verloren.

  	0 (verzögert). Schreiben)
  1 (Echtzeitschreiben, Echtzeitbürsten)	Jedes Mal, wenn eine Transaktion übermittelt wird, wird das Protokoll im Redo-Log-Puffer in den Betriebssystempuffer geschrieben und fsync() wird aufgerufen, um es dorthin zu leeren die Redo-Log-Datei. Bei dieser Methode gehen auch bei einem Systemabsturz keine Daten verloren. Da jedoch jede Übermittlung auf die Festplatte geschrieben wird, ist die E/A-Leistung schlecht.
  2 (Echtzeitschreiben, verzögertes Bürsten)	Jede Übermittlung wird nur in den Betriebssystempuffer geschrieben, und dann wird jede Sekunde fsync() aufgerufen, um das Protokoll im Betriebssystempuffer in die Redo-Log-Datei zu schreiben.
  Redo-Log-Aufzeichnungsformat Redolog verwendet eine feste Größe und ein zyklisches Schreibformat. Wenn das Redolog voll ist, wird es erneut von Anfang an geschrieben. Warum ist es so konzipiert? Der Hauptzweck des Redo-Logs besteht darin, den Bedarf für das Leeren von Datenseiten zu reduzieren. Redolog zeichnet die Änderungen auf der Datenseite auf, aber wenn die Datenseite auch zurück auf die Festplatte geleert wird, werden diese Datensätze unbrauchbar. Wenn MySQL also feststellt, dass das vorherige Redolog abgelaufen ist, überschreiben die neuen Daten die ungültigen Daten. Wie kann man also beurteilen, ob es abgedeckt werden sollte? Das obige Bild ist ein schematisches Diagramm der Schreibposition der Redo-Log-Datei, die die aktuell von Redolog aufgezeichnete Log-Sequenznummer LSN (Log-Sequenznummer) darstellt. Wenn die Datenseite zurück auf die Festplatte geleert wurde, wird die LSN in der Redo-Log-Datei aktualisiert, was darauf hinweist, dass die Daten vor dieser LSN auf die Festplatte geschrieben wurden. Diese LSN ist der Prüfpunkt. Der Teil zwischen Schreibposition und Prüfpunkt ist der Ersatzteil von Redolog, der zum Aufzeichnen neuer Datensätze verwendet wird. Der Teil zwischen Prüfpunkt und Schreibposition ist der geänderte Teil der Datenseite, der von Redolog aufgezeichnet wurde, aber die Datenseite wurde zu diesem Zeitpunkt noch nicht auf die Festplatte zurückgespült. Wenn die Schreibposition den Kontrollpunkt einholt, schiebt sie zunächst den Kontrollpunkt nach vorne, räumt die Position und zeichnet dann ein neues Protokoll auf. Beim Starten von innodb wird immer ein Wiederherstellungsvorgang durchgeführt, unabhängig davon, ob es beim letzten Mal normal oder ungewöhnlich heruntergefahren wurde. Während der Wiederherstellung wird zuerst die LSN auf der Datenseite überprüft. Wenn diese LSN kleiner ist als die LSN im Redolog, dh die Schreibposition, bedeutet dies, dass die nicht abgeschlossenen Vorgänge auf der Datenseite im Redolog aufgezeichnet werden. und dann beginnt es am nächstgelegenen Kontrollpunkt und beginnt mit der Synchronisierung der Daten. Ist es möglich, dass die LSN auf der Datenseite größer ist als die LSN im Redolog? Die Antwort ist natürlich möglich. Wenn dies geschieht, wird der Teil, der über das Redolog hinausgeht, nicht wiederholt, da dies selbst bedeutet, dass das, was getan wurde, nicht wiederholt werden muss. Der Unterschied zwischen Redo Log und Binlog Anwendbare Szenarien: Dies lässt sich am Unterschied zwischen Binlog und Redo-Log erkennen: Das Binlog-Log wird nur zur Archivierung verwendet, und wenn man sich nur auf Binlog verlässt, sind die Funktionen nicht absturzsicher. Aber nur das Redo-Protokoll funktioniert nicht, da das Redo-Protokoll nur für InnoDB gilt und die Datensätze im Protokoll nach dem Schreiben auf die Festplatte überschrieben werden. Daher müssen Binlog und Redo-Log gleichzeitig aufgezeichnet werden, um sicherzustellen, dass die Daten nicht verloren gehen, wenn die Datenbank heruntergefahren und neu gestartet wird. Zweistufige Übermittlung Das Obige stellt Redolog und Binlog kurz vor. Beim Ändern von Daten werden diese Änderungen gespeichert, aber eines ist ein physisches Protokoll und das andere ist ein logisches Protokoll. Wie haben sie den Änderungsprozess durchgeführt? Angenommen, es gibt eine Aktualisierungsanweisung, die jetzt ausgeführt werden soll, Aktualisierung von Tabellenname, Satz c=c+1, wobei ID=2, der Ausführungsprozess ist wie folgt: Suchen Sie zuerst die Datensatz-ID=2; Der Executor geht zu der von der Engine angegebenen Datenzeile, addiert 1 zu diesem Wert, ruft eine neue Datenzeile ab und ruft dann die Engine-Schnittstelle auf, um diese neue Datenzeile zu schreiben. Die Engine aktualisiert diese neu Datenzeile in den Speicher und aktualisiert diese gleichzeitig. Der Vorgang wird in Redolog aufgezeichnet, das sich zu diesem Zeitpunkt im Vorbereitungszustand befindet. Dann wird der Executor darüber informiert, dass die Ausführung abgeschlossen ist und die Transaktion jederzeit übermittelt werden kann. Der Executor generiert das Binlog dieser Operation und schreibt das Binlog auf die Festplatte Transaktionsschnittstelle, und die Engine schreibt das Redo-Log in den Commit-Status und die Aktualisierung ist abgeschlossen. Das schematische Diagramm sieht wie folgt aus: Bereiten Sie diesen Prozess zum Aufteilen des Redo-Log-Schreibens in zwei Schritte vor und Commit wird als zweiphasiges Commit bezeichnet. Sowohl Redolog als auch Binlog können verwendet werden, um den Commit-Status einer Transaktion darzustellen, und das zweiphasige Commit dient dazu, die beiden Zustände logisch konsistent zu halten. Wenn Sie kein zweiphasiges Commit verwenden, sondern zuerst das eine und dann das andere schreiben, kann es zu Problemen kommen. Zu diesem Zeitpunkt wird das Update noch als Beispiel verwendet. Gehen Sie davon aus, dass die aktuelle ID = 2 ist und ein Feld c = 0 vorhanden ist. Analysieren Sie jeweils die folgenden Situationen: Schreiben Sie zuerst Redolog und dann Binlog. Nehmen Sie an, dass Redolog zuerst geschrieben wird, Binlog jedoch noch nicht. MySQL wird eine plötzliche Ausnahme verursachen, die einen Neustart verursacht. Da das Redolog bereits geschrieben wurde, sind die geänderten Datensätze auch nach dem Neustart des Systems noch vorhanden, sodass der Wert von c in dieser Zeile nach der Wiederherstellung 1 ist. Aufgrund des Systemneustarts ist dieser Eintrag jedoch nicht im Binlog vorhanden. Bei einer späteren Sicherung des Protokolls ist diese Aussage im gespeicherten Binlog nicht vorhanden. Dann werden Sie feststellen, dass, wenn Sie dieses Binlog zum Wiederherstellen der temporären Bibliothek verwenden müssen, die temporäre Bibliothek dieses Mal nicht aktualisiert wird, da das Binlog dieser Anweisung verloren geht. Der Wert von c in der wiederhergestellten Zeile ist 0 derselbe wie der Wert der Originalbibliothek. Schreiben Sie zuerst Binlog und dann Redolog. Wenn Sie beim Schreiben von Redolog zuerst Binlog schreiben und dann das System neu starten. Nach dem Neustart gibt es im Redolog keine Aufzeichnungen über die Änderung von c, und der Wert von c ist zu diesem Zeitpunkt immer noch 0. Aber das Protokoll „Change c from 0 to 1“ wurde im Binlog aufgezeichnet. Wenn daher später Binlog zum Wiederherstellen verwendet wird, wird eine weitere Transaktion ausgegeben. Der Wert von c in der wiederhergestellten Zeile ist 1, was sich vom Wert in der ursprünglichen Datenbank unterscheidet. Zusammenfassend lässt sich sagen: Wenn Sie zuerst ein bestimmtes Protokoll schreiben und dann ein weiteres Protokoll schreiben, stimmt der Status der Datenbank nicht mit dem Status der mithilfe von Binlog wiederhergestellten Bibliothek überein. 3. Undolog wird hauptsächlich zum Aufzeichnen des Status vor der Änderung eines bestimmten Zeilendatensatzes verwendet. Verwenden Sie „Undolog“, um beim Rollback der Transaktion den Zustand der Datensätze vor Beginn der Transaktion wiederherzustellen. Auch die Atomizität und Dauerhaftigkeit von Transaktionen werden durch Undolog erreicht. Das Rückgängig-Protokoll zeichnet hauptsächlich die logischen Änderungen der Daten auf. Beispielsweise entspricht eine INSERT-Anweisung einem DELETE-Rückgängig-Protokoll. Für jede UPDATE-Anweisung entspricht sie einem entgegengesetzten UPDATE-Rückgängig-Protokoll, sodass sie bei Auftreten eines Fehlers rückgängig gemacht werden kann zurück zum Datenstand vor der Transaktion. Während des Datenwiederherstellungsprozesses kann die Kombination von Binlog und Redolog die Genauigkeit der Datenwiederherstellung sicherstellen. Der Funktionsablauf von undolog ist wie folgt: Schreiben Sie die vorab geänderte Version in das Rückgängig-Protokoll, bevor die Transaktion beginnt; Starten Sie die Änderung und speichern Sie die geänderten Daten im Speicher; Persistentes Undolog auf die Festplatte; Transaktionsübermittlung; Wie Redolog muss auch das Undolog vor den Datenseiten zurück auf die Festplatte geleert werden. Wenn die Rückgängigmachung abgeschlossen ist, können die darin aufgezeichneten Informationen verwendet werden, um die Transaktion rückgängig zu machen und die Daten wiederherzustellen. Bei einer Transaktion können dieselben Daten mehrmals geändert werden. Müssen also die Datensätze vor jeder Änderung im Undolog aufgezeichnet werden? In diesem Fall ist die Anzahl der Undolog-Protokolle zu groß und Redolog kommt zu diesem Zeitpunkt ins Spiel. Wenn in einer Transaktion derselbe Datensatz geändert wird, zeichnet Undolog nur den ursprünglichen Datensatz auf, bevor die Transaktion beginnt. Wenn dieser Datensatz erneut geändert wird, zeichnet Redolog nachfolgende Änderungen auf. Während des Datenwiederherstellungsprozesses wird die Datenwiederherstellung durch die Koordination der Redolog- und Undolog-Funktionen sowie Roll-Forward- und Rollback-Vorgänge abgeschlossen. Der Ablauf ist wie folgt: Redo Log Binlog Dateigröße Die Größe des Redo Log ist festgelegt. Binlog kann die Größe jeder Binlog-Datei über den Konfigurationsparameter max_binlog_size festlegen. Implementierungsmethode Redo-Log wird von der InnoDB-Engine-Ebene implementiert, nicht alle Engines verfügen darüber. Binlog wird von der Serverschicht implementiert. Aufzeichnungsmethode: Redo-Protokollaufzeichnungen in einer Schleife. Beim Schreiben bis zum Ende wird zum Anfang zurückgekehrt, um Protokolle zu schreiben Schleife. binlog wird durch Anhängen aufgezeichnet. Wenn die Dateigröße größer als der angegebene Wert ist, werden nachfolgende Protokolle in neuen Dateien aufgezeichnet. Redo-Protokoll eignet sich für die Absturzwiederherstellung (absturzsicher) binlog Geeignet für Master-Slave-Replikation und Datenwiederherstellung

Das obige ist der detaillierte Inhalt vonSo verwenden Sie das Binlog, Redo-Log und Undo-Log von MySQL. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!