Detaillierte Erläuterung der Architektur und Funktionen von InnoDB (Zusammenfassung der Lesehinweise zur InnoDB-Speicher-Engine)

Hintergrund-Threads

•Hauptthread

Der Kern-Hintergrundthread ist hauptsächlich für die asynchrone Aktualisierung der Pufferpooldaten auf der Festplatte verantwortlich. Beispiele hierfür sind das Aktualisieren von schmutzigen Seiten, das Zusammenführen von Einfügepuffern, das Wiederverwenden von Undo-Seiten usw.

Operationen einmal pro Sekunde:

1. Der Protokollpuffer wird auf die Festplatte geschrieben, auch wenn die Transaktion nicht festgeschrieben wurde. Dieser Vorgang wird immer ausgeführt, sodass die Commit-Zeit unabhängig von der Größe der Transaktion sehr kurz ist.

2. Wenn der IO-Druck sehr gering ist (die Anzahl der innerhalb von 1 Sekunde auftretenden IOs beträgt weniger als 5 % von innodb_io_capacity), führen Sie den Einfügepuffer von 5 % von innodb_io_capacity zusammen.

3. Wenn das Verhältnis der schmutzigen Seiten größer ist als innodb_max_dirty_pages_cnt, schreiben Sie die schmutzigen Seiten in den innodb_io_capacity-Pufferpools auf die Festplatte. Andernfalls wird, wenn innodb_adaptive_flush aktiviert ist, die entsprechende Anzahl zu aktualisierender schmutziger Seiten basierend auf buf_flush_get_desired_flush_rate ausgewählt.

Bedienung alle 10 Sekunden:

1. Wenn der E/A-Vorgang in den letzten 10 Sekunden kürzer ist als innodb_io_capacity, schreiben Sie die schmutzigen Seiten in den innodb_io_capacity-Pufferpools auf die Festplatte.

2. 5 % der innodb_io_capacity-Einfügepuffer zusammenführen.

3. Leeren Sie den Protokollpuffer auf die Festplatte.

4. Löschen Sie nutzlose Rückgängig-Seiten.

5. Wenn der Anteil schmutziger Seiten im Pufferpool 70 % überschreitet, aktualisieren Sie die schmutzigen Seiten von innodb_io_capacity erneut auf die Festplatte. Andernfalls werden 10 % der schmutzigen innodb_io_capacity-Seiten gelöscht.

Hintergrundschleife (wenn die Datenbank im Leerlauf ist oder geschlossen ist):

1. Löschen Sie nutzlose Rückgängig-Seiten.

2. Innodb_io_capacity-Einfügepuffer zusammenführen.

Flush-Schleife (Datenbank im Leerlauf):

1. Aktualisieren Sie schmutzige Seiten von innodb_io_capacity

•IO-Thread

Die Innodb-Speicher-Engine macht umfassenden Gebrauch von AIO, und der IO-Thread ist hauptsächlich für den Rückruf von IO-Anfragen verantwortlich. Dies kann mithilfe der Parameterlisten innodb_read_io_threads und innodb_write_io_threads angepasst werden.

•Thread löschen

Nachdem die Transaktion bestätigt wurde. Das mit dieser Transaktion verbundene Undolog wird möglicherweise nicht mehr benötigt. Purge Thread wird verwendet, um unnötige Undo-Seiten wiederzuverwenden.

•Seitenreiniger-Thread

Verantwortlich für das Aktualisieren fehlerhafter Seiten. Reduzieren Sie die Arbeit des Master-Threads und die Blockierung von Benutzerabfrage-Threads.

Speicherpufferpool

Bei Änderungsvorgängen an Seiten in der Datenbank werden zunächst die Seiten im Pufferpool geändert und dann in einer bestimmten Häufigkeit auf die Festplatte aktualisiert. Dies bedeutet, dass bei jeder Änderung einer Seite im Pufferpool kein Zurückspeichern auf die Festplatte ausgelöst wird, sondern dass die Seite über die Checkpoint-Technologie zurück auf die Festplatte gespeichert wird. Die Größe des Pufferpools kann über innodb_buffer_pool_size konfiguriert werden.

Die Datenseitentypen des Pufferpools umfassen: Datenseiten, Indexseiten, Rückgängig-Seiten, Einfügepuffer, adaptive Hash-Indizes, in InnoDB gespeicherte Sperrinformationen und Wörterbuchinformationen.

Die InnoDB-Speicher-Engine erlaubt jetzt mehrere Pufferpoolinstanzen. Dadurch wird die Anzahl der Sperrkonflikte durch Hashing auf verschiedene Pufferpoolinstanzen reduziert. Dieser Parameter kann über innodb_buffer_pool_instance festgelegt werden.

Der Pufferpool ist ein großer Speicherbereich, der von der Datenbank mithilfe des LRU-Algorithmus verwaltet wird. Aber berücksichtigen Sie den Vorgang des vollständigen Tabellenscans. Daher wird der einfache LRU-Algorithmus nicht übernommen. Die Mittelpunktposition wurde der LRU-Liste hinzugefügt. Die neu gelesene Seite wird nicht direkt an den Anfang der LRU-Liste gestellt, sondern an die mittlere Position. Standardmäßig 5/8 der LRU-Listenlänge. Gesteuert durch den Parameter innodb_old_blocks_pct.

Puffer einfügen

Bei Einfüge- und Aktualisierungsvorgängen nicht gruppierter Indizes fügt die Innodb-Speicher-Engine nicht direkt in die Indexseite ein, sondern in den Einfügepuffer. Anschließend werden die Insertbuffer- und Hilfsindexblattknoten in einer bestimmten Häufigkeit zusammengeführt. Dabei werden häufig mehrere zufällige Einfügungen in einer einzigen Operation kombiniert. Deutlich verbesserte Leistung beim Einfügen nicht gruppierter Indizes.

Innodb verwendet Insertbuffer-Bedingungen:

• Der Index ist ein nicht gruppierter Index

•Der Index ist nicht eindeutig (wenn er eindeutig ist, müssen Sie den Index finden, um die Eindeutigkeit sicherzustellen)

Interne Implementierung des Einfügepuffers

Die Datenstruktur des Insert Buffer ist ein B+-Baum. Seit MySQL 4.1 gibt es global nur noch einen B+-Baum, der für das Einfügen von Puffern für Hilfsindizes aller Tabellen zuständig ist. Darüber hinaus wird dieser Baum in einem gemeinsam genutzten Tablespace gespeichert, der standardmäßig ibdata1 ist. Wenn Sie zum Wiederherstellen der Tabellendaten nur die unabhängige Tablespace-IBD-Datei verwenden, kann dies daher fehlschlagen. Außerdem ist es notwendig, die Hilfsindizes der Tabelle über die Einfügepufferdaten wiederherzustellen.

Die Nicht-Blattknoten des Einfügepufferers speichern den Abfrageschlüssel, der als Leerzeichen (4 Bytes) + Markierung (1 Byte) + Offset (4 Bytes) aufgebaut ist. „space“ gibt die Tabellenbereichs-ID der Tabelle an, in der sich der Datensatz befindet, und „offset“ gibt den Seitenoffset an. Der Marker dient der Kompatibilität mit der alten Version.

Die Blattpunkte des Einfügepuffer werden wie folgt aufgebaut: Leerzeichen + Markierung + Offset + Metadaten + Datensätze. Leerzeichen, Markierung und Offset haben die gleiche Bedeutung wie oben. Der IBUF_REC_OFFSET_COUNT in den Metadaten speichert eine zwei Byte große Ganzzahl, die zum Sortieren der Reihenfolge verwendet wird, in der Datensätze in den Einfügepuffer gelangen. Durch erneuten Aufruf dieser Sequenz können wir den richtigen Wert des Datensatzes ermitteln. Ab der 5. Spalte des Insert Buffer-Blattknotens werden die tatsächlich eingefügten Datensätze angezeigt.

Nach dem Aktivieren des Insert Buffer-Index können Datensätze von Hilfsindexseiten in den Insert Buffer B+-Baum eingefügt werden. Um sicherzustellen, dass jeder Merge-Insert in den Puffer erfolgreich ist, muss es eine Stelle geben, an der der verfügbare Platz jeder Hilfsindexseite markiert werden kann. „Insert Buffer“ ist mit einer speziellen Seite vom Typ „Insert Buffer Bitmap“ gekennzeichnet. Jede Insert Buffer Bitmap-Seite wird zum Verfolgen von 16384 Seiten oder 256 Zonen verwendet. Jede Insert Buffer Bitmap-Seite befindet sich auf der zweiten Seite der 16384 Seiten. Jede Hilfsindexseite belegt 4 Bytes in der Bitmap, die hauptsächlich dazu dient, die verfügbare Anzahl Hilfsindexseiten anzuzeigen.

Zusammenführen/Einfügen-Puffer

In folgenden Fällen werden Datensätze im Insert Buffer in den eigentlichen Hilfsindex eingebunden:

• Hilfsindexseiten werden in den Pufferpool gelesen;

• Wenn die Seite „Puffer-Bitmap einfügen“ feststellt, dass auf der zusätzlichen Indexseite kein freier Speicherplatz vorhanden ist;

• Master-Thread-Planung;

Auf diese Weise werden mehrere Datensatzvorgänge auf der Hilfsindexseite durch einen Vorgang in die ursprüngliche Hilfsindexseite zusammengeführt, wodurch die Leistung verbessert wird.

Doppeltes Schreiben

InsertBuffer verbessert die Leistung der Innodb-Speicher-Engine, während die beiden Schreibvorgänge die Zuverlässigkeit der Datenseiten verbessern.

Sie fragen sich vielleicht: Kann ein Schreibfehler nicht über das Redo-Protokoll behoben werden? Dies ist zwar eine Lösung, Sie müssen jedoch wissen, dass das Redo-Protokoll die physischen Vorgänge der Seite aufzeichnet, z. B. Offset 800 oder das Schreiben des „aaa“-Datensatzes. Wenn die Seite jedoch bereits beschädigt ist, ist eine erneute Erstellung sinnlos. Dies bedeutet, dass vor dem Ändern einer Seite eine korrekte Kopie der Seite vorhanden sein muss. Wenn ein Schreibfehler auftritt, wird die Seite zunächst anhand der Kopie der Seite wiederhergestellt und dann erneut ausgeführt. Dies ist ein doppelter Schreibvorgang.

Double Write besteht aus zwei Teilen, ein Teil ist der Double Write-Puffer im Speicher. Der andere Teil besteht aus 128 aufeinanderfolgenden Seiten im gemeinsam genutzten Tabellenbereich auf der physischen Festplatte, der dieselbe Größe wie der Arbeitsspeicher (2 MB) hat. Beim Aktualisieren von Seiten im Pufferpool werden diese nicht direkt auf die Festplatte geschrieben, sondern von memcpy in den Doppelschreibpuffer. Anschließend werden 1 Million Daten in zwei Stapeln über den Doppelschreibpuffer in den gemeinsam genutzten Tabellenbereich geschrieben, und anschließend wird fsync sofort aufgerufen, um die Festplatte zu synchronisieren. Dieser Schreibaufwand ist nicht sehr groß, da die doppelten Schreibvorgänge auf den Seiten des gemeinsam genutzten Tablespace kontinuierlich erfolgen. Nachdem das Schreiben der Double-Write-Seite abgeschlossen ist, handelt es sich beim Schreiben der Seiten im Double-Write-Puffer in jeden Tabellenbereich um einen diskreten Schreibvorgang.

Wenn das Betriebssystem beim Schreiben der Seite auf die Festplatte abstürzt. Während der Wiederherstellung kann dann eine Kopie der Seite von der Double-Write-Buffer-Seite im gemeinsam genutzten Tablespace gefunden werden. Kopieren Sie es in den Tablespace und wenden Sie dann das Redo-Log an.

Adaptiver HASH-Index

Die Innodb-Speicher-Engine überwacht Abfragen auf jeder Indexseite der Tabelle und stellt möglicherweise fest, dass die Erstellung eines Hash-Index die Abfragegeschwindigkeit verbessern kann. Anschließend wird ein Hash-Index erstellt, der sogenannte Adaptive Hash Index (AHI).

AHI hat die Anforderung, dass die aufeinanderfolgenden Zugriffsmuster auf diese Seite gleich sein müssen. Beispielsweise kann für einen gemeinsamen Index wie (a, b) das Zugriffsmuster wie folgt aktiviert werden:

WO a = xxx

WO a = xxx und b = yyy

Der gleiche Zugriffsmodus bedeutet die gleichen Abfragebedingungen. Wenn die oben genannten Abfragevorgänge abwechselnd ausgeführt werden. AHI wird nicht festgelegt.

Darüber hinaus erfordert AHI, dass bei 100-maligem Aufrufen desselben Musters die Seite N-mal über das Muster aufgerufen wird, wobei N = Datensätze auf der Seite * 1/16

Benachbarte Seiten aktualisieren

Beim Aktualisieren einer verschmutzten Seite prüft die Innodb-Speicher-Engine alle Seiten in dem Bereich, in dem sich die Seite befindet. Wenn es sich um eine verschmutzte Seite handelt, wird sie gemeinsam aktualisiert.

Asynchrone E/A

Innodb verwendet asynchrone IO zur Handhabung von Festplattenvorgängen.

Check Point-Technologie

Um Datenverlust zu vermeiden, wenden Transaktionsdatenbanksysteme im Allgemeinen eine Write-Ahead-Log-Strategie an. Das heißt, wenn eine Transaktion festgeschrieben wird, wird zuerst das Redo-Protokoll geschrieben und dann die Seite geändert.

Allerdings kann das Redo-Protokoll nicht unendlich wachsen und der Pufferwert (schmutzige Seiten, die nicht auf die Festplatte geschrieben wurden) kann nicht unendlich sein. Auch wenn die Größe unendlich sein kann, dauert die Wiederherstellung nach einem Datenbankabsturz sehr lange. Daher wird Check Point-Technologie benötigt, die folgende Probleme lösen kann:

• Reduzieren Sie die Datenbankwiederherstellungszeit;

• Wenn der Pufferpool nicht ausreicht, können schmutzige Seiten auf die Festplatte geschrieben werden.

• Wenn das Redo-Protokoll nicht verfügbar ist (Redo-Protokolle werden wiederverwendet), werden fehlerhafte Seiten auf die Festplatte geschrieben.

Wenn die Datenbank nach einem Absturz neu gestartet wird, müssen nicht alle Protokolle erneut erstellt werden. Da die Seiten vor dem Prüfpunkt auf die Festplatte aktualisiert wurden, muss die Datenbank nach dem Prüfpunkt nur die Redo-Protokolle wiederherstellen. Dadurch wird die Erholungszeit erheblich verkürzt.

Bei Innodb werden die Versionen tatsächlich per LSN (Log Sequence Number) verglichen. Die LSN ist eine 8-Byte-Zahl. Jede Seite hat eine LSN, das Redo-Protokoll hat eine LSN und der CheckPoint hat ebenfalls eine LSN. Dies kann mit dem folgenden Befehl beobachtet werden

mysql> Engine-InnoDB-Status anzeigen\G;

.............

Protokollsequenznummer 92561351052

Protokoll gelöscht bis 92561351052

Letzter Kontrollpunkt bei 92561351052

Die oben aufgeführte ausführliche Erklärung der InnoDb-Systemarchitektur und -Funktionen (Zusammenfassung der Lesehinweise zur InnoDB-Speicher-Engine) ist der gesamte Inhalt, den der Herausgeber mit Ihnen teilt. Ich hoffe, dass er Ihnen als Referenz dienen kann. Ich hoffe auch, dass Sie 123WORDPRESS.COM unterstützen werden.