Das Konzept von MTR in MySQL

MTR steht für Mini-Transaktion. Wie der Name schon sagt, kann man darunter „kleinste Transaktion“ verstehen. In MySQL wird der Vorgang eines atomaren Zugriffs auf die zugrundeliegende Seite als Mini-Transaktion bezeichnet. Die atomare Operation bedeutet hier, dass entweder alle erfolgreich sind oder alle fehlschlagen und es keinen Zwischenzustand gibt.

MTR wird hauptsächlich zum Schreiben von Undo- und Redo-Protokollen verwendet. Wenn wir beispielsweise einen Datensatz in einen B+-Baumindex einfügen möchten, ist die Einfügung entweder erfolgreich oder schlägt fehl. Dieser Vorgang kann als MTR-Vorgang bezeichnet werden. Während dieses Vorgangs wird eine Reihe von Redo-Protokollen generiert. Dieser Protokollsatz ist bei der Wiederherstellung nach einem MySQL-Absturz ein unteilbares Ganzes.

Wenn wir eine Transaktion haben, die 3 Anweisungen enthält, sieht das konzeptionelle Diagramm von MTR wie folgt aus:

Mini-Transaktionen folgen im Allgemeinen drei Prinzipien:

• 1. Die Fix-Regeln
• 2. WAL
• 3. Force-Log beim Commit

Hier erklären wir diese drei Prinzipien:

1. Die Fix-Regeln

Bevor wir die erste Regel erklären, müssen wir das Konzept des Latch in MySQL verstehen. In MySQL ist Latch eine leichte Sperre. Im Gegensatz zu Lock sperrt es nur für sehr kurze Zeit. In InnoDB kann Latch in Mutex (Mutex) und RWLock (Lese-/Schreibsperre) unterteilt werden. Sein Zweck besteht darin, die Richtigkeit gleichzeitiger Threads sicherzustellen, die kritische Ressourcen bedienen.

Nachdem wir nun das Latch-Konzept verstanden haben, schauen wir uns die Fix-Regel an:

Um eine Datenseite zu ändern, müssen Sie den X-Latch dieser Datenseite abrufen.

Für den Zugriff auf eine Seite ist der Erhalt eines S-Latch oder eines X-Latch erforderlich.

Die Verriegelung, die die Seite hält, wird erst freigegeben, wenn der Vorgang zum Ändern oder Zugreifen auf die Seite abgeschlossen ist.

2. WAL

Ich glaube, jeder ist mit der WAL-Technologie vertraut. Sie ist der grundlegende Grund, warum die Innodb-Speicher-Engine die Wiederherstellung nach einem Absturz unterstützt. Das heißt, bevor eine Datenseite persistent gespeichert wird, muss zuerst die entsprechende Protokollseite im Speicher persistent gespeichert werden.

3. Force-Log beim Commit

Dieses Prinzip ist sehr wichtig. Es bedeutet, dass beim Festschreiben einer Transaktion alle von ihr generierten MTR-Protokolle auf das Persistenzgerät übertragen werden müssen, um die Absturzwiederherstellungslogik sicherzustellen.

Der Grund für die Einführung von MTR ist die Vorbereitung auf die spätere Einführung der Redo-Log-Optimierung in MySQL 8.0. In MySQL 5.7 stellt MTR die Atomizität von Vorgängen innerhalb von Transaktionen sicher. Wenn der Benutzer eine Operation ausführt, wird die Datenseite aktualisiert und gleichzeitig das Redo-Log geschrieben. mtr ist der Träger des Redo-Logs und existiert in der privaten Variable jeder Verbindungssitzung. Wenn mtr übermittelt wird, wird das lokale Redo-Protokoll in den globalen log_buffer kopiert. Um die Ordnung des Redo-Protokolls sicherzustellen, ist für den Zugriff auf den log_buffer eine Sperre erforderlich. Diese Sperre ist das oben erwähnte Mutex. Unter dem Schutz dieser Sperre muss zusätzlich zum Kopieren des lokalen Protokolls in den globalen Puffer die Datenseite zur Flush_list hinzugefügt werden, damit der Hintergrundthread den Datenfluss durchführen und den Datenbankprüfpunkt dabei unterstützen kann, weiter fortzufahren. Daher ist diese Sperre in alten MySQL-Versionen sehr wettbewerbsfähig. MySQL 8.0 hat dieses Problem optimiert, was in den folgenden Artikeln detailliert analysiert wird.

Oben finden Sie ausführliche Informationen zum Konzept von MTR in MySQL. Weitere Informationen zu MySQL MTR finden Sie in den anderen verwandten Artikeln auf 123WORDPRESS.COM!