Heim >Datenbank >MySQL-Tutorial >So verwenden Sie das Binlog, Redo-Log und Undo-Log von MySQL
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.
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;
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
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.
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.
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
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. | ||||||||||||||
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.
|
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!