Zusammenfassung der 7 Protokolltypen in MySQL

In MySQL gibt es folgende Protokolldateien:

1: Protokoll wiederholen
2: Rollback-Protokoll (Undo-Protokoll)
3: Binärprotokoll (binlog)
4: Fehlerprotokoll
5: Langsames Abfrageprotokoll
6: Allgemeines Abfrageprotokoll (allgemeines Protokoll)
7: Relaisprotokoll

Unter ihnen sind Redo-Protokolle und Rollback-Protokolle eng mit Transaktionsvorgängen verbunden, und Binärprotokolle haben auch eine gewisse Beziehung zu Transaktionsvorgängen. Diese drei Protokolle sind für das Verständnis von Transaktionsvorgängen in MySQL von großer Bedeutung.

1. Protokoll wiederholen

Wirkung:
Stellen Sie die Dauerhaftigkeit der Transaktionen sicher. Das Redo-Log zeichnet den Status nach der Ausführung der Transaktion auf und dient der Wiederherstellung der durch die erfolgreiche Transaktion aktualisierten Daten, die nicht in die Datendatei geschrieben wurden. Um zu verhindern, dass bei einem Fehler fehlerhafte Seiten auf die Festplatte geschrieben werden, führen Sie die Transaktion beim Neustart des MySQL-Dienstes basierend auf dem Redo-Protokoll erneut aus, um die Dauerhaftigkeit der Transaktion zu gewährleisten.

Inhalt:
Das physische Formatprotokoll zeichnet die Änderungsinformationen der physischen Datenseiten auf und sein Redo-Protokoll wird sequenziell in die physische Datei der Redo-Protokolldatei geschrieben.

Wann wird es generiert:
Nach dem Start einer Transaktion wird ein Redo-Log generiert. Das Redo-Log wird nicht auf die Festplatte geschrieben, wenn die Transaktion festgeschrieben wird, sondern während der Ausführung der Transaktion in die Redo-Log-Datei.

Bei Veröffentlichung:
Wenn die schmutzigen Seiten der entsprechenden Transaktionen auf die Festplatte geschrieben werden, ist die Mission des Redo-Protokolls abgeschlossen und der vom Redo-Protokoll belegte Speicherplatz kann wiederverwendet (überschrieben) werden.

Die entsprechende physische Datei:
Standardmäßig befinden sich die entsprechenden physischen Dateien in ib_logfile1&ib_logfile2 im Datenverzeichnis der Datenbank.
innodb_log_group_home_dir gibt den Pfad an, in dem sich die Protokolldateigruppe befindet. Der Standardwert ist ./, was bedeutet, dass sie sich im Datenverzeichnis der Datenbank befindet.
innodb_log_files_in_group gibt die Anzahl der Dateien in der Redo-Log-Dateigruppe an, der Standardwert ist 2

Die Größe und Anzahl der Dateien werden durch die folgenden beiden Parameter konfiguriert:
innodb_log_file_size Die Größe der Redo-Logdatei.
innodb_mirrored_log_groups gibt die Anzahl der Protokollspiegeldateigruppen an, der Standardwert ist 1

andere:
Ein sehr wichtiger Punkt ist: Wann wird das Redo-Protokoll auf die Festplatte geschrieben? Wie bereits erwähnt, wird die Festplatte nach Beginn der Transaktion schrittweise beschrieben.
Der Grund, warum das Redo-Log nach dem Start der Transaktion schrittweise in die Redo-Log-Datei geschrieben wird und nicht unbedingt nach dem Commit der Transaktion in den Redo-Log-Cache geschrieben wird, liegt darin, dass das Redo-Log einen Pufferbereich Innodb_log_buffer hat. Die Standardgröße von Innodb_log_buffer beträgt 8 MB (hier ist 16 MB eingestellt). Die Innodb-Speicher-Engine schreibt das Redo-Log zuerst in innodb_log_buffer.

Anschließend werden die Protokolle im InnoDB-Protokollpuffer auf die folgenden drei Arten auf die Festplatte geschrieben:

Der Master-Thread führt einmal pro Sekunde das Leeren des Innodb_log_buffer in die Redo-Log-Datei aus.

Bei jeder Transaktion wird ein Commit ausgeführt und das Redo-Log in die Redo-Log-Datei geschrieben.

Wenn im Redo-Log-Cache weniger als die Hälfte des verfügbaren Speicherplatzes vorhanden ist, wird der Redo-Log-Cache in die Redo-Log-Dateien geleert.

Daraus können wir ersehen, dass das Redo-Protokoll auf mehr als eine Weise auf die Festplatte geschrieben wird. Insbesondere bei der ersten Methode ist Innodb_log_buffer in die Redo-Protokolldatei eine geplante Aufgabe des Master-Thread-Threads.

Daher erfolgt das Schreiben von Redo-Protokollen auf die Festplatte nicht notwendigerweise beim Festschreiben der Transaktion, sondern beginnt schrittweise mit dem Start der Transaktion.

Darüber hinaus zitiere ich die Originalworte aus „MySQL Technology Insider Innodb Storage Engine“ (Seite 37):

Auch wenn eine Transaktion nicht festgeschrieben wurde, leert die Innodb-Speicher-Engine den Redo-Log-Cache jede Sekunde in die Redo-Log-Datei.

Dies ist wichtig zu wissen, da es gut erklären kann, warum die Commit-Zeit selbst der größten Transaktionen sehr kurz ist.

2. Rollback-Protokoll (Undo-Protokoll)

Wirkung:
Stellt die Atomizität der Daten sicher und speichert eine Version der Daten, bevor die Transaktion erfolgt, die für Rollbacks verwendet werden kann. Es kann auch Lesevorgänge unter Multi-Version Concurrency Control (MVCC) bereitstellen, d. h. Lesevorgänge ohne Sperren.

Inhalt:
Logische Protokolle stellen Daten nur dann in den Zustand vor der Transaktion zurück, wenn Rückgängig-Vorgänge ausgeführt werden, nicht aber, wenn auf physischen Seiten gearbeitet wird. Dies unterscheidet sich von Redo-Protokollen.

Wann wird es generiert:
Vor dem Start der Transaktion wird die aktuelle Version in einem Undo-Protokoll generiert. Undo generiert auch Redo, um die Zuverlässigkeit des Undo-Protokolls sicherzustellen.

Bei Veröffentlichung:
Nachdem eine Transaktion festgeschrieben wurde, wird das Undo-Protokoll nicht sofort gelöscht, sondern zur Bereinigung in eine verknüpfte Liste eingefügt. Der Bereinigungsthread ermittelt, ob andere Transaktionen die Versionsinformationen vor der vorherigen Transaktion in der Tabelle im Undo-Segment verwenden, und entscheidet, ob der Protokollspeicherplatz des Undo-Protokolls bereinigt werden kann.

Die entsprechende physische Datei:
Vor MySQL 5.6 befindet sich der Undo-Tablespace im Rollback-Segment des gemeinsam genutzten Tablespace. Der Standardname des gemeinsam genutzten Tablespace lautet ibdata und befindet sich im Datendateiverzeichnis.
Nach MySQL 5.6 kann der Undo-Tablespace als unabhängige Datei konfiguriert werden, muss aber vorher in der Konfigurationsdatei konfiguriert werden. Dies wird nach der Initialisierung der Datenbank wirksam und die Anzahl der Undo-Logdateien kann nicht geändert werden. Wenn vor der Initialisierung der Datenbank keine entsprechende Konfiguration durchgeführt wird, kann er nicht als unabhängiger Tablespace konfiguriert werden.

Die Konfigurationsparameter für unabhängige Undo-Tablespaces nach MySQL 5.7 lauten wie folgt:
innodb_undo_directory = /data/undospace/ – das Speicherverzeichnis des Undo-unabhängigen Tablespaces innodb_undo_logs = 128 – das Rollback-Segment ist 128 KB groß innodb_undo_tablespaces = 4 – gibt 4 Undo-Protokolldateien an. Wenn der gemeinsam genutzte Tablespace für Undo verwendet wird, speichert dieser gemeinsam genutzte Tablespace nicht nur die Undo-Informationen, der gemeinsam genutzte Tablespace verwendet standardmäßig das MySQL-Datenverzeichnis und seine Eigenschaften werden durch den Parameter innodb_data_file_path konfiguriert.

andere:
Undo ist eine Version der geänderten Daten, die vor Beginn der Transaktion gespeichert wurde. Wenn ein Undo-Protokoll generiert wird, wird auch ein Redo-Protokoll generiert, das dem Mechanismus zum Schutz der Transaktionspersistenz ähnelt.
Standardmäßig wird die Undo-Datei im gemeinsam genutzten Tablespace, also in der Datei ibdatafile, gespeichert. Wenn in der Datenbank große Transaktionsvorgänge stattfinden, wird eine große Menge an Undo-Informationen generiert und alle im gemeinsam genutzten Tablespace gespeichert.
Daher kann der gemeinsam genutzte Tablespace sehr groß werden. Wenn das Undo-Log den gemeinsam genutzten Tablespace verwendet, wird der „erweiterte“ gemeinsam genutzte Tablespace standardmäßig nicht automatisch verkleinert und kann dies auch nicht.
Daher ist die Konfiguration eines „unabhängigen Undo-Tablespace“ nach MySQL 5.7 sehr wichtig.

3. Binärprotokoll (binlog)

Wirkung:
Wird für die Replikation verwendet. Bei der Master-Slave-Replikation verwendet die Slave-Datenbank das Binärprotokoll der Master-Datenbank zur Wiedergabe, um eine Master-Slave-Synchronisierung zu erreichen.
Wird für die zeitpunktbezogene Wiederherstellung einer Datenbank verwendet.

Inhalt:
Protokolle im logischen Format können einfach als SQL-Anweisungen in ausgeführten Transaktionen betrachtet werden.
Es handelt sich dabei jedoch nicht nur um eine einfache SQL-Anweisung, sondern es enthält die umgekehrten Informationen der ausgeführten SQL-Anweisung (Hinzufügen, Löschen und Ändern). Dies bedeutet, dass Löschen dem Löschen selbst und seinem umgekehrten Einfügen entspricht. Aktualisieren entspricht den Informationen der Versionen vor und nach der Ausführung von Aktualisieren. Einfügen entspricht den Informationen von Löschen und Einfügen selbst.
Nachdem Sie mysqlbinlog zum Parsen von Binlog verwendet haben, wird ein Teil der Wahrheit klar.
Daher können wir auf der Grundlage von Binlog eine Flashback-Funktion ähnlich wie Oracle erreichen, die tatsächlich auf den Protokolldatensätzen in Binlog basiert.

Wann wird es generiert:
Wenn eine Transaktion festgeschrieben wird, werden alle SQL-Anweisungen in der Transaktion (eine Transaktion kann mehreren SQL-Anweisungen entsprechen) gleichzeitig in einem bestimmten Format im Binärprotokoll aufgezeichnet.
Der offensichtliche Unterschied besteht darin, dass das Redo-Protokoll nicht unbedingt auf die Festplatte geschrieben wird, wenn die Transaktion festgeschrieben wird. Das Redo-Protokoll wird nach dem Start der Transaktion schrittweise auf die Festplatte geschrieben.
Daher erfolgt die Übermittlung von Transaktionen, auch bei größeren Transaktionen, sehr schnell. Wenn bin_log jedoch aktiviert ist, kann die Übermittlung größerer Transaktionen langsamer werden.
Dies liegt daran, dass das Binärprotokoll einmal geschrieben wird, wenn die Transaktion festgeschrieben wird, was durch Tests überprüft werden kann.

Bei Veröffentlichung:
Die Standardaufbewahrungszeit von Binlog wird durch den Parameter expire_logs_days konfiguriert. Dies bedeutet, dass inaktive Protokolldateien automatisch gelöscht werden, wenn die Generierungszeit die durch expire_logs_days konfigurierte Anzahl von Tagen überschreitet.

Die entsprechende physische Datei:
Der Pfad der Konfigurationsdatei lautet log_bin_basename. Die Binlog-Protokolldatei hat die angegebene Größe. Wenn die Protokolldatei die angegebene Maximalgröße erreicht, wird ein Rollover durchgeführt und eine neue Protokolldatei generiert.
Jede Binlog-Protokolldatei wird über eine einheitliche Indexdatei organisiert.

andere:
Eine der Funktionen des Binärprotokolls besteht darin, die Datenbank wiederherzustellen, was dem Redo-Protokoll sehr ähnlich ist. Viele Leute haben sie verwechselt, aber die beiden sind grundsätzlich unterschiedlich: Das Redo-Protokoll soll die Persistenz von Transaktionen sicherstellen, was auf Transaktionsebene erfolgt, während das Binärprotokoll als Wiederherstellungsfunktion auf Datenbankebene erfolgt (natürlich kann es auch auf Transaktionsebene präzise sein). Obwohl beide die Bedeutung der Wiederherstellung haben, sind die Datenschutzebenen unterschiedlich.
Unterschiedlicher Inhalt: Redo-Log ist ein physisches Protokoll, das eine physische Aufzeichnung der Änderungen der Datenseite ist, und Binlog ist ein logisches Protokoll, das einfach als Aufzeichnung von SQL-Anweisungen betrachtet werden kann. Darüber hinaus sind der Zeitpunkt, zu dem die Protokolle generiert werden, der Zeitpunkt, zu dem sie freigegeben werden können, und der Bereinigungsmechanismus, zu dem sie freigegeben werden können, völlig unterschiedlich.
Die Effizienz der Datenwiederherstellung ist höher als die des logischen Anweisungsprotokolls Binlog.
In Bezug auf die Schreibreihenfolge von Redo-Log und Binlog beim Festschreiben einer Transaktion muss diese strikt konsistent sein, um die Konsistenz zwischen Master und Slave während der Master-Slave-Replikation sicherzustellen (natürlich umfasst dies auch die Verwendung von Binlog für die zeitpunktbezogene Wiederherstellung). MySQL vervollständigt die Konsistenz von Transaktionen durch einen zweiphasigen Festschreibungsprozess, d. h. die Konsistenz von Redo-Log und Binlog. Theoretisch wird zuerst das Redo-Log und dann das Binlog geschrieben. Die Transaktion ist erst dann wirklich abgeschlossen, wenn beide Protokolle erfolgreich festgeschrieben (auf die Festplatte geschrieben) wurden.

4. Fehlerprotokoll

Das Fehlerprotokoll zeichnet Informationen zum Starten und Stoppen von mysqld sowie Fehler auf, die während des Serverbetriebs auftreten. Standardmäßig ist die Systemfehlerprotokollfunktion deaktiviert und Fehlermeldungen werden an die Standardfehlerausgabe ausgegeben.
Es gibt zwei Möglichkeiten, den Protokollpfad anzugeben:
1) Bearbeiten Sie my.cnf und schreiben Sie log-error=[Pfad]
2) Fehlerprotokoll über Befehlsparameter mysqld_safe –user=mysql –log-error=[path] &

Befehl zum Anzeigen des Fehlerprotokolls (wie unten gezeigt)

5. Allgemeines Abfrageprotokoll

Das allgemeine Protokoll zeichnet jede Abfrage oder jeden Befehl auf, den der Server empfängt, unabhängig davon, ob die Abfrage oder der Befehl korrekt ist oder sogar Syntaxfehler enthält. Das Datensatzformat ist {Zeit, ID, Befehl, Argument}. Da der MySQL-Server kontinuierlich Protokolle aufzeichnen muss, verursacht das Aktivieren des allgemeinen Protokolls einen erheblichen Systemaufwand. Daher deaktiviert MySQL das allgemeine Protokoll standardmäßig.

Zeigen Sie die Methode zur Protokollspeicherung an: Zeigen Sie Variablen wie „log_output“ an.

Wenn Sie mysql> set global log_output='table' festlegen, werden die Protokollergebnisse in einer Tabelle namens gengera_log aufgezeichnet. Die Standard-Engine für diese Tabelle ist CSV.
Wenn Sie die Tabellendaten in einer Datei festlegen, setzen Sie global log_output=file;
Legen Sie den Protokolldateipfad für das allgemeine Protokoll fest:
Setzen Sie die globale General-Log-Datei = "/tmp/general.log".
Allgemeines Protokoll aktivieren: set global general_log=on;
Allgemeines Protokoll deaktivieren: setze global general_log=off;

Dann verwenden Sie: „globale Variablen wie ‚general_log‘ anzeigen“

6. Langsames Abfrageprotokoll

Das langsame Protokoll zeichnet Abfrageanweisungen auf, deren Ausführung zu lange dauert und die keine Indizes verwenden, und meldet Fehler für Select-, Update-, Delete- und Insert-Anweisungen. Das langsame Protokoll zeichnet nur Anweisungen auf, die erfolgreich ausgeführt wurden.

1. Überprüfen Sie die langsame Abfragezeit:

Variablen wie „long_query_time“ anzeigen; Standard 10 s 

2. Überprüfen Sie die Konfiguration der langsamen Abfrage:

Status wie „%slow_queries%“ anzeigen; 

3. Zeigen Sie den Protokollpfad für langsame Abfragen an:

Variablen wie „%slow%“ anzeigen; 

4. Aktivieren Sie das langsame Protokoll

Überprüfen Sie, ob es aktiviert ist:

Dies ist das Ende dieses Artikels über die 7 Arten von Protokollzusammenfassungen in MySQL. Weitere relevante MySQL-Protokollinhalte finden Sie in früheren Artikeln auf 123WORDPRESS.COM oder in den folgenden verwandten Artikeln. Ich hoffe, dass jeder 123WORDPRESS.COM in Zukunft unterstützen wird!