Was sind MySQL-Dirty-Pages?

Schmutzige Seiten (Speicherseiten)

Clean Page: Die Daten im Speicher und auf der Festplatte sind konsistent. Dirty Page: Die Daten im Speicher und auf der Festplatte sind inkonsistent.

Warum werden schmutzige Seiten angezeigt?

Normalerweise werden bei schnellen Aktualisierungsvorgängen sämtliche Daten in den Speicher und in Protokolle geschrieben.
Es erfolgt keine sofortige Synchronisierung mit der Datenträgerdatenseite. Zu diesem Zeitpunkt stimmt der Inhalt der Speicherdatenseite nicht mit der Datenträgerdatenseite überein, was wir als fehlerhafte Seite bezeichnen.
Dabei handelt es sich um den Speicherverwaltungsmechanismus von MySQL

Kurze Beschreibung des Speicherverwaltungsmechanismus

Der Puffer enthält Listen dieser drei Kategorien. Dies sind: LRUList, FreeList und FlushList.
Wenn die Datenbank gerade gestartet wurde, befinden sich keine Datenseiten in der LRU-Liste. FreeList speichert kostenlose Seiten.

• Wenn eine Seite gelesen werden muss, wird eine freie Seite aus der FreeList abgerufen und nach dem Lesen der Daten in die LRUlist eingefügt.
• Wenn in der FreeList keine freien Seiten vorhanden sind, wird die letzte Seite in der LRU-Liste gemäß dem LRU-Algorithmus eliminiert.
• Wenn eine Seite in der LRU-Liste geändert wird, wird die Seite zu einer schmutzigen Seite und wird der FlushList hinzugefügt.

Hinweis: Diese Seite befindet sich derzeit sowohl in der LRU-Liste als auch in der Flush-Liste.

Zusammenfassung: LRUList (verwaltet gelesene Seiten) und FreeList (verwaltet freie Seiten) werden verwendet, um die Seitenverfügbarkeit zu verwalten; FlushList (verwaltet schmutzige Seiten) wird verwendet, um die Aktualisierung schmutziger Seiten zu verwalten

Während des Prozesses der Synchronisierung von Daten fehlerhafter Seiten mit der Festplatte, wenn eine SQL-Anweisung auf der Datenseite der Festplatte ausgeführt wird. Die Ausführungsgeschwindigkeit wird langsamer sein

Ist es möglich, Daten nur durch Verlassen auf den Puffer zu ändern und zu lesen?

Wenn die Datenänderung und das Lesen ausschließlich auf dem Speicherpuffer basieren, gehen bei einem Datenbankabsturz alle Daten im Speicher verloren. Daher verwendet MySQL das zuvor erwähnte Redo-Log, um die Datenwiederherstellung nach einem abnormalen Neustart zu implementieren. Eine Einführung in das Redo-Log finden Sie in diesem Artikel: MySQL-Redo-Log und Binlog

Einfach ausgedrückt wird vor dem Aktualisieren des Puffers ein Redo-Protokoll geschrieben, um sicherzustellen, dass die Daten im Puffer nach einem abnormalen Neustart normal wiederhergestellt werden können.

Warum schmutzige Seiten aktualisiert werden müssen

• Wenn die Daten, wie oben erwähnt, nur im Puffer gespeichert werden, stürzt die Datenbank ab und die Speicherdaten gehen verloren. Es muss also auf die Festplatte geschrieben werden.
• Wenn das Redo-Protokoll unendlich groß ist oder viele Dateien enthält, gibt es im System eine große Anzahl von Änderungsvorgängen. Sobald ein Absturz auftritt, ist die Wiederherstellungszeit sehr lang.

Daher müssen wir die schmutzigen Seiten im Speicher natürlich nach bestimmten Regeln auf der Festplatte aktualisieren. Mit dem Aktualisierungsvorgang können das Puffergrößenproblem und das Redo-Log-Größenproblem gelöst werden.

• Der Puffer muss nicht unendlich sein, da er auf der Festplatte gespeichert werden kann.
• Das Redo-Protokoll muss nicht unendlich sein, da der entsprechende Teil der Daten im Redo-Protokoll freigegeben werden kann, sobald es auf der Festplatte gespeichert ist.

Es gibt vier Szenarien zum Löschen schmutziger Seiten:

• Wenn das Redo-Protokoll voll ist, unterbricht MySQL alle Aktualisierungsvorgänge und synchronisiert die diesem Teil des Protokolls entsprechenden fehlerhaften Seiten mit der Festplatte.
• Wenn der Systemspeicher nicht ausreicht, müssen einige Datenseiten gelöscht werden. Wenn schmutzige Seiten gelöscht werden, müssen sie zuerst mit der Festplatte synchronisiert werden.
• Wenn MySQL der Meinung ist, dass das System im Leerlauf ist, synchronisiert es bei Gelegenheit die Speicherdaten mit der Festplatte, ohne dass es zu Leistungsproblemen kommt.
• Wenn MySQL normal heruntergefahren wird, synchronisiert MySQL alle schmutzigen Seiten im Speicher mit der Festplatte, sodass MySQL beim nächsten Start die Daten direkt von der Festplatte lesen kann und die Startgeschwindigkeit sehr hoch ist. Dies hat keine Leistungsprobleme.

Die Auswirkungen

1 Wenn das Redo-Protokoll voll ist, versuchen Sie, dies zu vermeiden. Andernfalls wird die Aktualisierung des gesamten Systems gestoppt. Zu diesem Zeitpunkt wird die Schreibleistung 0 und die Aktualisierung kann erst durchgeführt werden, nachdem die Synchronisierung der entsprechenden fehlerhaften Seite des Protokolls abgeschlossen ist. Dies führt dazu, dass die SQL-Anweisung sehr langsam ausgeführt wird.

Dies ist das Ende dieses Artikels über MySQL-Dirty-Pages. Weitere relevante MySQL-Dirty-Pages 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!