Detaillierter Informationsaustausch über das MySQL-Protokollsystem

Jeder, der schon einmal an einem großen System gearbeitet hat, weiß, dass die Rolle von Protokollen nicht unterschätzt werden darf. In späteren Phasen eines Projekts werden Entscheidungen zur Projektoptimierung und zu Upgrades häufig auf der Grundlage von Protokollen getroffen. Deshalb darf beim Erlernen von MySQL der Protokollteil nicht fehlen. Die Optimierungen, die wir im Interview in der tatsächlichen Anwendung besprochen haben, wurden alle aus den Protokollen gewonnen. Durch die systematische Untersuchung von MySQL-Protokollen können wir Probleme präzise lokalisieren und unsere Arbeitsqualität verbessern. Darüber hinaus konzentrieren sich die folgenden Protokollreihen auf den Betrieb und die Wartung von DBA, vermitteln Ihnen ein systematisches Verständnis der Konfiguration verschiedener Aspekte von MySQL, lernen sich selbst und Ihre Feinde kennen und machen MySQL zu einem Data Warehouse, mit dem Sie vertraut sind.

1. MySQL-Protokolltypen

Standardmäßig werden alle MySQL-Protokolle als Dateien im Stammverzeichnis der Datenbank gespeichert:

[root@roverliang-Daten]# pwd
/usr/local/webserver/extend_lib/mysql/data
[root@roverliang-Daten]# ls
auto.cnf ibdata1 ib_logfile0 ib_logfile1 mysql mytest performance_schema roverliang roverliang.err roverliang.pid test

Es gibt die folgenden MySQL-Protokolltypen:

1. Fehlerprotokoll (Fehler), Informationen zum Starten, Ausführen oder Stoppen der MySQL-Dienstinstanz.
2. Allgemeines Abfrageprotokoll (allgemein), alle SQL-Anweisungen oder MySQL-Befehle, die von der MySQL-Dienstinstanz ausgeführt werden.
3. Binärprotokoll (binär), alle auf der Datenbank ausgeführten Update-Anweisungen, ausgenommen Select- und Show-Anweisungen.
4. Langsames Abfrageprotokoll (langsam), SQL-Anweisungen, deren Ausführungszeit den Einstellungswert „long_query_time“ überschreitet, oder SQL-Anweisungen, die keine Indizes verwenden.

MySQL-Protokollcache

In einem schnellen, stabilen und zuverlässigen System spielt der Cache eine entscheidende Rolle. Die MySQL-Protokollverarbeitung verwendet auch einen Caching-Mechanismus. MySQL-Logs werden zunächst im Arbeitsspeicher des MySQL-Servers gespeichert. Wird die angegebene Speicherkapazität überschritten, werden die im Arbeitsspeicher befindlichen Logs auf den externen Speicher geschrieben (bzw. geleert) und in Form einer Datenbanktabelle oder Datei dauerhaft auf der Festplatte gespeichert.

3. MySQL-Fehlerprotokoll

Das MySQL-Fehlerprotokoll zeichnet hauptsächlich detaillierte Informationen zu jedem Start und Stopp der MySQL-Dienstinstanz sowie während des Betriebs der MySQL-Instanz generierte Warnungen oder Fehlermeldungen auf. Im Gegensatz zu anderen Protokollen muss das MySQL-Fehlerprotokoll aktiviert werden und kann nicht deaktiviert werden.

Der Name der Fehlerprotokolldatei lautet standardmäßig: hostname.err. Allerdings werden im Fehlerprotokoll nicht alle Fehlermeldungen aufgezeichnet. Es werden nur kritische Fehler aufgezeichnet, die während des Betriebs der MySQL-Dienstinstanz auftreten.

mysql> Variablen wie 'log_error' anzeigen\G
*************************** 1. Reihe ***************************
Variablenname: log_error
Wert: /usr/local/webserver/extend_lib/mysql/data/roverliang.err
1 Zeile im Satz (0,02 Sek.)

4. Allgemeines MySQL-Protokoll

Das allgemeine MySQL-Abfrageprotokoll zeichnet alle Vorgänge der MySQL-Dienstinstanz auf, z. B. Auswählen, Aktualisieren, Einfügen, Löschen usw., unabhängig davon, ob der Vorgang erfolgreich ausgeführt wurde. Außerdem gibt es Informationen darüber, wie der MySQL-Client eine Verbindung zum MySQL-Server herstellt und die Verbindung trennt, unabhängig davon, ob die Verbindung erfolgreich war oder nicht. Es gibt drei Parameter, die sich auf das allgemeine MySQL-Abfrageprotokoll beziehen.

[]()allgemeines_protokoll

mysql> Variablen wie „general_log“ anzeigen;
+---------------+-------+
| Variablenname | Wert |
+---------------+-------+
| general_log | AUS |
+---------------+-------+
1 Zeile im Satz (0,01 Sek.)

Sie können die allgemeine Abfrageprotokollierung aktivieren, indem Sie @@global.general_log = 1 festlegen.

mysql> setze @@global.general_log = 1;
mysql> Variablen wie „general_log“ anzeigen;
+---------------+-------+
| Variablenname | Wert |
+---------------+-------+
| general_log | EIN |
+---------------+-------+

Das Ändern von MySQL-Variablen auf diese Weise wird jedoch nur wirksam, während die aktuelle MySQL-Instanz ausgeführt wird. Nach dem Neustart wird MySQL auf den Standardzustand zurückgesetzt. Um es dauerhaft zu machen, müssen Sie die my.cnf-Datei von MySQL ändern. Fügen Sie nach der Konfigurationsdatei hinzu:

general_log = 1
general_log_file

Sobald das allgemeine Abfrageprotokoll aktiviert ist, erstellt die MySQL-Dienstinstanz automatisch eine allgemeine Abfrageprotokolldatei. Der Parameter general_log_file legt den physischen Speicherort der allgemeinen Abfrageprotokolldatei fest. wie folgt:

mysql> Variablen wie „general_log_file“ anzeigen;
+------------------+----------------------------------------------------------+
| Variablenname | Wert |
+------------------+----------------------------------------------------------+
| allgemeine_Protokolldatei | /usr/local/webserver/extend_lib/mysql/data/roverliang.log |
+------------------+----------------------------------------------------------+

Hinweis: Da das allgemeine Abfrageprotokoll fast alle MySQL-Vorgänge aufzeichnet, wird bei Datenbankservern mit häufigem Datenzugriff die Leistung der Datenbank erheblich beeinträchtigt, wenn das allgemeine Abfrageprotokoll von MySQL aktiviert ist. Daher wird empfohlen, das allgemeine Abfrageprotokoll zu deaktivieren. Nur in besonderen Zeiträumen, z. B. wenn Sie bestimmte spezielle Abfrageprotokolle verfolgen müssen, können Sie das normale Abfrageprotokoll vorübergehend öffnen.

log_ausgabe

Der Parameter log_output legt den Inhalt des normalen Abfrageprotokolls und des langsamen Abfrageprotokolls fest, der in der Datenbanktabelle gespeichert werden soll. Sie können set @@global.log_output='table' verwenden, um allgemeine Abfrageprotokolle und langsame Abfrageprotokolle in der allgemeinen Tabelle und der slow_log-Tabelle in der MySQL-Systemdatenbank zu speichern. Es ist erwähnenswert, dass die Speicher-Engine dieser beiden Tabellen CSV ist. Danach können SQL-Anweisungen verwendet werden, wenn neue allgemeine Abfrageprotokollinhalte angezeigt werden.

setze @@global.log_output = 'Tabelle';
mysql> Variablen wie „log_output“ anzeigen;
+---------------+-------+
| Variablenname | Wert |
+---------------+-------+
| log_output | TABELLE |
+---------------+-------+

5. MySQL-Protokoll für langsame Abfragen (langsames Protokoll)

Fragen im Zusammenhang mit langsamen Abfrageprotokollen. Während des Interviews spricht der Interviewer sehr gerne über diese Probleme. In der Vergangenheit konnte ich nur über die MySQL-Master-Slave-Architektur sprechen und MySQL unter verschiedenen Gesichtspunkten optimieren, aber ich habe nicht wirklich verstanden, wie man langsame Abfragen und zugehörige Konfigurationen aktiviert.

Mithilfe des MySQL-Protokolls für langsame Abfragen können Sie Abfrageanweisungen, deren Ausführung zu lange dauert oder die keine Indizes verwenden, effektiv verfolgen. Hierzu gehören Select-Anweisungen, Update-Anweisungen, Delete-Anweisungen und Insert-Anweisungen, die bei der Optimierung von Abfragen helfen. Ein weiterer Unterschied zum normalen Abfrageprotokoll besteht darin, dass das langsame Abfrageprotokoll nur erfolgreich ausgeführte Abfrageanweisungen enthält. Es gibt fünf Parameter, die sich auf das MySQL-Protokoll für langsame Abfragen beziehen.

1. langsames_Abfrageprotokoll

slow_query_log legt fest, ob das Protokoll für langsame Abfragen aktiviert ist.

mysql> Variablen wie „slow_query_log“ anzeigen;
+----------------+--------+
| Variablenname | Wert |
+----------------+--------+
| slow_query_log | AUS |
+----------------+--------+

2. slow_query_log_file

Sobald das Protokoll für langsame Abfragen aktiviert ist, erstellt die MySQL-Instanz automatisch eine Protokolldatei für langsame Abfragen. In der durch slowquerylog_file angegebenen Datei wird der Inhalt des langsamen Abfrageprotokolls gespeichert. Die Änderungsmethode ist die gleiche wie oben gezeigt. Gehen Sie zum Bearbeiten direkt zur Datei my.cnf.

3. lange_Abfragezeit

long_query_time legt den Zeitschwellenwert für langsame Abfragen fest. Der Standardschwellenwert beträgt 10 s.

4. log_quries_not_using_indexes

log_quries_not_using_indexes Gibt an, ob Abfragen, die keine Indizes verwenden, im Protokoll für langsame Abfragen protokolliert werden sollen, unabhängig davon, wie schnell die Abfrage ist.

mysql> setze @@global.log_queries_not_using_indexes=1;

mysql> Variablen wie „log_queries_not_using_indexes“ anzeigen;
+-------------------------------+----------+
| Variablenname | Wert |
+-------------------------------+----------+
| log_queries_not_using_indexes | EIN |
+-------------------------------+----------+

5. log_ausgabe

Legen Sie das Ausgabeformat des normalen Abfrageprotokolls und des langsamen Abfrageprotokolls mit zwei Werten fest: Datei und Tabelle.

6. Anzeigen von MySQL-Protokollen für langsame Abfragen

Der Parameter log_output kann das Ausgabeformat des langsamen Abfrageprotokolls festlegen. Der Standardwert ist FILE, kann aber auf TABLE gesetzt werden.

mysql> Beschreibung mysql.slow_log;
+----------------+---------------------+
| Feld | Typ |
+----------------+---------------------+
| Startzeit | Zeitstempel |
| Benutzerhost | Mitteltext |
| Abfragezeit | Zeit |
| Sperrzeit | Zeit |
| Zeilen_gesendet | int(11) |
| untersuchte Zeilen | int(11) |
| varchar(512) |
| letzte_Einfüge-ID | int(11) |
| Einfüge-ID | int(11) |
| Server-ID | int(10) ohne Vorzeichen |
| sql_text | Mitteltext |
| Thread-ID | Bigint(21) ohne Vorzeichen |
+----------------+---------------------+

Dabei gilt: lock_time gibt die Zeit an, in der SQL bei der Ausführung durch eine Sperre blockiert ist. rows_send gibt die Anzahl der Zeilen an, die nach der Ausführung von SQL zurückgegeben werden. rows_examined gibt die Anzahl der Datensätze an, die bei der Ausführung von SQL tatsächlich gescannt wurden.

Es ist jedoch nicht üblich, TABLE zum Speichern langsamer Abfrageprotokolle zu verwenden. Wenn das Geschäftsvolumen groß ist, wirkt sich dies auf den Hauptdienst des Systems aus. Wir können FILE zum Speichern von Protokollen verwenden. Wenn Sie MySQL installieren, wird das Tool mysqldumpslow.pl standardmäßig im MySQL-Bin-Verzeichnis installiert, um die Protokolle langsamer Abfragen zu analysieren. Die Verwendung dieses Tools unter Windows kann einige Konfigurationen erfordern, die über den Rahmen dieses Artikels hinausgehen. Um mehr über Systemdienste zu erfahren, ist es besser, auf Linux umzusteigen. Für Befehle und Tools unter Linux können Sie den Befehl selbst + die Option --help verwenden, um die Hilfedokumentation anzuzeigen.

-s gibt die Sortiermethode an

Unteroptionen: c, t, l, r

c: Anzahl der Ausführungen der SQL-Anweisung
t: Ausführungszeit
l: Wartezeit für die Sperre
r: Gibt die Anzahl der Datenelemente zurück
at, al, ar sind die Durchschnittswerte des entsprechenden TLR. -t: bedeutet, die ersten N Datensätze zurückzugeben.

-g: Abkürzung für grep. Enthält Fuzzy-Matching

Häufig verwendete Methoden sind die folgenden:

//Gibt die 20 SQL-Anweisungen mit der höchsten Anzahl an Zugriffen zurück./mysqldumpslow -sc -t 20 /usr/local/webserver/extend_lib/mysql/data/roverliang-slow.log

//Gibt die 20 SQL-Anweisungen mit der größten Anzahl von Rückgabedatensätzen zurück./mysqldumpslow -sr -t 20 /usr/local/webserver/extend_lib/mysql/data/roverliang-slow.log

//Gibt SQL-Anweisungen zurück, die like enthalten./mysqldumpslow -g 'like' 20 /usr/local/webserver/extend_lib/mysql/data/roverliang-slow.log 

7. Binäres Protokoll

Binärprotokolle unterscheiden sich von den zuvor erwähnten Protokollen. Binärprotokolle können nicht direkt mit dem Textbetrachter „cat“ oder „less“ angezeigt werden. Es müssen professionelle Werkzeuge verwendet werden. Das Binärprotokoll zeichnet hauptsächlich die Änderungen in der Datenbank auf, sodass es zur Synchronisierung zwischen der Master- und der Slave-Bibliothek verwendet werden kann. Der Inhalt umfasst hauptsächlich alle Datenbankaktualisierungsvorgänge, Use-Anweisungen, Insert-Anweisungen, Delete-Anweisungen, Update-Anweisungen, Create-Anweisungen, Alter-Anweisungen und Drop-Anweisungen. Um es prägnanter und verständlicher zusammenzufassen: Alle Vorgänge, die Datenänderungen beinhalten, müssen im Binärprotokoll aufgezeichnet werden.

Starten Sie die binäre Protokollierung. Verwenden Sie Show-Variablen wie „log_bin“\G, um zu sehen, ob die binäre Protokollierung aktiviert ist.

mysql> Variablen wie 'log_bin' anzeigen\G
*************************** 1. Reihe ***************************
Variablenname: log_bin
    Wert: OFF
1 Zeile im Satz (0,00 Sek.)

mysql> setze @@global.log_bin=1;
FEHLER 1238 (HY000): Die Variable „log_bin“ ist eine schreibgeschützte Variable.
MySQL> 

Sie können sehen, dass log_bin standardmäßig nicht aktiviert ist und eine schreibgeschützte Variable ist. Sie müssen es in my.cnf konfigurieren und dann MySQL neu starten. Nach dem Neustart von MySQL mit „service mysql restart“ finden Sie im Datenverzeichnis eine generierte Datei 1.000001. Tatsächlich wird bei jedem Neustart von MySQL eine Datei wie diese im Verzeichnis generiert und der Dateiname wird der Reihe nach erhöht. Darüber hinaus erstellt MySQL in diesem Verzeichnis eine binäre Log-Indexdatei. Sie können den Speicherort der Indexdatei anzeigen, indem Sie den Befehl „show variables like 'log_bin_index'\G“ ausführen und sie dann mit dem Befehl „cat“ anzeigen. Sie werden feststellen, dass der relative Pfad der Binärdatei darin aufgezeichnet ist.

Sie können die mit MySQL gelieferten Tools verwenden, um das Binärprotokoll anzuzeigen. Der genaue Speicherort befindet sich im Bin-Verzeichnis von MySQL. Allgemeine Optionen für den Befehl mysqlbinlog:

-s Protokollinhalte übersichtlich anzeigen
-v Protokollinhalt im detaillierten Modus anzeigen
-d=Datenbankname zeigt nur den Protokollinhalt der angegebenen Datenbank an
-o=n Ignoriert die ersten n Zeilen von MySQL-Befehlen im Protokoll
-r=Datei Schreibt den angegebenen Inhalt in die angegebene Datei

--start-datetime
Anzeige der Protokollinhalte innerhalb des angegebenen Zeitraums
--stop-datetime

--start-position
Anzeige des Protokollinhalts innerhalb des angegebenen Positionsintervalls
--Stoppposition

Abrufen der aktuellen Binärprotokolldatei

mysql> Masterstatus anzeigen;
+----------+----------+--------------+------------------+-------------------+
| Datei | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+----------+----------+--------------+------------------+-------------------+
| 1,000002 | 120 | | | |
+----------+----------+--------------+------------------+-------------------+
1 Zeile im Satz (0,00 Sek.)

Wiederherstellen von Daten mithilfe von Binärprotokollen

Die Syntax ist einfach:

mysqlbinlog -s 1.000001 | mysql -h 192.168.1.188 -u root -p

Auf mysqlbinlog können Parameter wie --start-datetime, --stop-datetime, start-position und stop-position folgen.

Mit den beiden Parametern --start-datetime und --stop-datetime können Daten zeitpunktbasiert wiederhergestellt werden.

Start- und Stoppposition können verwendet werden, um Daten an detaillierteren Betriebspunkten wiederherzustellen.

Mit dem MySQL-Binärprotokoll verbundene Parameter

mysql> Variablen wie „%binlog%“ anzeigen;
+-----------------------------------------+----------------------+
| Variablenname | Wert |
+-----------------------------------------+----------------------+
| binlog_cache_size | 32768 |
| binlog_checksum | CRC32 |
| binlog_direct_non_transactional_updates | AUS |
| binlog_error_action | IGNORE_ERROR |
| binlog_format | ANWEISUNG |
| binlog_gtid_simple_recovery | AUS |
| binlog_max_flush_queue_time | 0 |
| binlog_order_commits | EIN |
| binlog_row_image | VOLL |
| binlog_rows_query_log_events | AUS |
| binlog_stmt_cache_size | 32768 |
| binlogging_impossible_mode | IGNORE_ERROR |
| innodb_api_enable_binlog | AUS |
| innodb_locks_unsafe_for_binlog | AUS |
| max_binlog_cache_size | 18446744073709547520 |
| max_binlog_size | 1073741824 |
| max_binlog_stmt_cache_size | 18446744073709547520 |
| vereinfachtes_binlog_gtid_recovery | AUS |
| sync_binlog | 0 |
+-----------------------------------------+----------------------+

max_binlog_size

maxbinlogsize Die Größe einer einzelnen binären Protokolldatei. Wird der Wert überschritten, wird eine neue Datei mit der Endung +1 erzeugt, ansonsten wird die Datei automatisch gelöscht.

binlog_cache_size

binlogcachesize Die Größe des Caches, der zum Speichern von Binärprotokollen im Speicher verwendet wird

sync_binlog

sync_binlog schreibt Binärprotokolle mehrmals in den Cache und beginnt mit der synchronen Aktualisierung in den externen Speicher (Festplatte).

log_slave_updates

logslvaeupdates für Master-Slave-Replikation

Bereinigen des Binärprotokolls

Grundsätzlich sollten die zu bereinigenden Protokolle zur dauerhaften Speicherung physisch auf anderen Speichergeräten gesichert werden. Dann empfehlen wir Ihnen die folgenden zwei weniger riskanten Reinigungsmethoden:

Der Erste:

purge master logs before '2017-02-16 00:00:00';

Zweiter Typ:

Legen Sie den Parameter expire_logs_days direkt in der MySQL-Konfigurationsdatei my.cnf fest, um die Ablauftage für Binärdateien festzulegen. Abgelaufene Binärdateien werden automatisch gelöscht. Es wird empfohlen, vor dem Löschen eine andere periodische geplante Aufgabe zu starten, um binäre Aufgaben regelmäßig zu sichern. Damit soll verhindert werden, dass sich einige Daten erst nach mehreren Tagen als falsch herausstellen und das Binärprotokoll automatisch gelöscht wird.

expire_logs_days=90

8. InnoDB-Transaktionsprotokoll

MySQL nutzt den Cache maximal aus, um die Effizienz des Datenzugriffs zu verbessern. Mit anderen Worten: Jedes Hochleistungssystem muss Cache verwenden, und Cache spielt auf allen Ebenen eine riesige Rolle. Fassen wir es auf einer höheren Ebene zusammen: Caching und Warteschlangen sind die einzige Möglichkeit, eine hohe Leistung zu erzielen. Dies stellt ein sehr heikles Problem für die Datenbank dar. Um ein effizienteres Lesen und Speichern der Daten zu gewährleisten, muss ein Cache verwendet werden. Um jedoch die Datenkonsistenz zu gewährleisten, muss sichergestellt werden, dass alle Daten korrekt in der Datenbank gespeichert werden und auch im Falle eines Unfalls wiederherstellbar sind. Wir wissen, dass InnoDB eine transaktionssichere Speicher-Engine ist und Konsistenz ein wichtiges Merkmal von Transaktions-ACID ist. Die InnoDB-Speicher-Engine erreicht Datenkonsistenz hauptsächlich durch das InnoDB-Transaktionsprotokoll. Das InnoDB-Transaktionsprotokoll umfasst das Redo-Protokoll und das Rollback-Protokoll.

Das InnoDB-Transaktionsprotokoll unterscheidet sich von dem oben genannten Protokoll. Das InnoDB-Transaktionsprotokoll wird von der InnoDB-Speicher-Engine selbst verwaltet und sein Inhalt kann vom Datenbankadministrator nicht gelesen werden.

Redo-Protokoll (Wiederholen)

Das Redo-Protokoll zeichnet hauptsächlich alle abgeschlossenen Transaktionen auf, d. h. die Protokolle, die festgeschrieben wurden. Standardmäßig werden die Werte der Redo-Protokolle in den Redo-Protokollen iblogfile0 und iblogfile1 aufgezeichnet.

[root@roverliang-Daten]# pwd
/usr/lokal/Webserver/MySQL/Daten
[root@roverliang-Daten]# ls ib*
ibdata1 ib_logfile0 ib_logfile1

Rollback-Protokoll (Rückgängig machen)

Das Rollback-Protokoll zeichnet hauptsächlich die nicht abgeschlossenen Transaktionen auf, die teilweise abgeschlossen und auf die Festplatte geschrieben wurden. Standardmäßig werden die Rollback-Protokollinformationen in der Tablespace-Datei, der gemeinsam genutzten Tablespace-Datei ibdata1 oder der exklusiven Tablespace-Datei ibd aufgezeichnet.

Aus der obigen Abbildung können wir ersehen, dass das Rollback-Protokoll standardmäßig in ibdta1 aufgezeichnet wird. Meine MySQL-Systemversion ist: 5.6.24.

Checkpoint-Mechanismus

Nach dem Absturz des MySQL-Servers führt InnoDB beim Neustart des MySQL-Dienstes aufgrund der Existenz von Redo-Protokollen (Redo) und Rollback-Protokollen (Undo) alle unvollständigen Transaktionen, die teilweise abgeschlossen und über das Rollback-Protokoll (Undo) auf die Festplatte geschrieben wurden, zurück. Führen Sie dann alle Transaktionen im Redo-Protokoll erneut aus, um alle Daten wiederherzustellen. Da die Datenmenge jedoch zu groß ist, hat InnoDB den Checkpoint-Mechanismus eingeführt, um die Wiederherstellungszeit zu verkürzen.

Schmutzige Seite

Wenn eine Transaktion einen Datensatz ändern muss, liest InnoDB zuerst den Datenblock, in dem sich die Daten befinden, aus dem externen Speicher auf die Festplatte. Nachdem die Transaktion festgeschrieben wurde, ändert InnoDB den Datensatz auf der Datenseite. Zu diesem Zeitpunkt ist die zwischengespeicherte Datenseite nicht mehr dieselbe wie der Datenblock im externen Speicher. Die Datenseite im Cache wird als „Dirty Page“ bezeichnet. Die „Dirty Page“ wird in den externen Speicher aktualisiert und wird zu einer „Clean Page“.

Hinweis: Eine Speicherseite ist standardmäßig 4 KB oder ein Vielfaches von 4 KB groß. Sie können sich den Speicher wie ein Buch vorstellen, das gelöscht werden kann. Jedes Mal, wenn MySQL Daten liest, fordert es einige leere Seiten aus dem Speicher an und schreibt dann darauf. Beim Aktualisieren der Daten auf der Festplatte werden die Datenseiten sofort gelöscht und für die Verwendung durch andere Programme bereitgestellt.

Protokollsequenznummer

Die Protokollsequenznummer (LSN) ist der Endpunkt jedes Protokolls im Protokollbereich, ausgedrückt als Byte-Offset, und wird während der Prüfpunkterstellung und Wiederherstellung verwendet.

Das Prinzip des Checkpoint-Mechanismus geht davon aus, dass zu einem bestimmten Zeitpunkt alle schmutzigen Seiten auf der Festplatte aktualisiert werden und alle Redo-Protokolle vor diesem Zeitpunkt nicht erneut erstellt werden müssen. Das System verwendet die Endposition des Redo-Protokolls zu diesem Zeitpunkt als Checkpoint, und die Redo-Protokolle vor dem Checkpoint müssen nicht erneut erstellt werden und können sicher gelöscht werden. Um den Redo-Log-Speicherplatz besser zu nutzen, verwendet InnoDb eine Round-Robin-Strategie zur Verwendung des Redo-Log-Speicherplatzes, sodass InnoDB über mindestens zwei Redo-Log-Dateien verfügt. Durch den Checkpoint-Mechanismus können die Transaktionen, die zum Zeitpunkt des Datenbankabsturzes abgeschlossen, aber noch nicht vollständig in den externen Speicher geschrieben wurden, über das Redo-Log wiederholt (rückgängig gemacht) werden, wodurch die Datenkonsistenz sichergestellt und die Wiederherstellungszeit verkürzt wird.

InnoDB-Redo-Log-Parameter (Redo)

innodb_log_buffer_size: Legt die Größe des Redo-Log-Cache fest.
innodb_log_files_in_group: Legt die Anzahl der Redo-Protokolle in der Protokolldateigruppe fest.
innodb_log_file_size: Legt die Größe der Redo-Logdatei fest. Je größer die Datei, desto länger dauert die Wiederherstellung.
innodb_mirrored_log_groups: Die Anzahl der Redo-Log-Mirror-Dateigruppen. Dies kann nur auf 1 gesetzt werden.
innodb_log_group_home_dir: Legen Sie das Verzeichnis fest, in dem die Protokolldateigruppe gespeichert wird. Das Standardverzeichnis ist das Stammverzeichnis der Datenbank.

InnoDB-Rollback-Protokollparameter (Rückgängig machen)

innodb_undo_directory: Legen Sie das Verzeichnis fest, in dem Rollback-Protokolle gespeichert werden.
innodb_undo_logs: Legen Sie die Rollback-Segmentgröße des Rollback-Protokolls fest. Der Standardwert beträgt 128 KB.
innodb_undo_tablespace: legt die Anzahl der Rollback-Protokolldateien fest, aus denen das Rollback-Protokoll besteht. Der Standardwert ist 0.
Warnung Besonderer Hinweis: Nach der Installation von MySQL müssen Sie die Rollback-Protokollparameter in my.cnf festlegen. Wenn Sie die Rollback-Protokollparameter nach dem Erstellen der Datenbank festlegen, meldet MySQL einen Fehler und kann nach dem Erstellen des Rollback-Protokolls nicht mehr geändert oder hinzugefügt werden.

9. Logdatei-Backup

Beim Sichern können Sie mit Flush Logs alle aktuellen Logdateien schließen und anschließend neue Logdateien erstellen. Nach dem Schließen der Logdatei können Sie diese physisch sichern. Darüber hinaus können Flush-Protokolle bestimmte Protokolltypen hinzufügen:

Fehlerprotokolle leeren
Allgemeine Protokolle leeren
Binärprotokolle leeren
langsame Protokolle leeren