Zusammenfassung einiger Gedanken zur Binlog-Optimierung in MySQL

Frage

Frage 1: Wie kann der Leistungsverlust behoben werden, der durch das Leeren des Redo-Protokolls beim Festschreiben einer Transaktion entsteht?

WAL ist eine gängige Technologie zum Erreichen der Transaktionspersistenz (D). Das Grundprinzip besteht darin, Transaktionsänderungen im Redo-Protokoll aufzuzeichnen. Das Redo-Protokoll wird sequenziell in der Reihenfolge des Anhängens geschrieben. Wenn eine Transaktion festgeschrieben wird, müssen Sie nur sicherstellen, dass das Redo-Log der Transaktion auf die Festplatte geschrieben wird. Durch das Ersetzen zufälliger Seitenschreibvorgänge durch sequentielle Redo-Log-Schreibvorgänge wird die Leistung des Datenbanksystems verbessert. Diese Lösung erfordert jedoch, dass das von jeder Transaktion generierte Redo-Protokoll einmal beim Festschreiben auf die Festplatte geschrieben wird, was ineffizient ist.

Frage 2: Die Reihenfolge der Übermittlung von Binlog- und Engine-Level-Transaktionen

Bei einer einzelnen Transaktion ist die Reihenfolge des Protokollschreibens zuerst das Redo-Log und dann das Binlog. Solange diese Reihenfolge eingehalten wird, kann die Korrektheit gewahrt werden. Bei einem Datenbanksystem mit hoher Parallelität können jedoch jederzeit viele Transaktionen gleichzeitig ausgeführt werden. Wir müssen außerdem bestimmte Mittel einsetzen, um die sequentielle Konsistenz des Binärprotokolls auf Serverebene und der Transaktionsübermittlung auf Engineebene aufrechtzuerhalten.

Die Aufrechterhaltung dieser sequentiellen Konsistenz dient eigentlich der Gewährleistung der Korrektheit des Backup-Tools Xtrabackup.

Wenn Binlog als Koordinator fungiert und die darin aufgezeichnete Transaktionsreihenfolge von der auf der Speichermodulebene aufgezeichneten Reihenfolge abweicht, können Lücken in den Speicherorten des vom Sicherungstool (Innodb Hot Backup) abgerufenen Sicherungssatzes auftreten. Da das Sicherungstool das Redo-Protokoll kopiert, wird die Binärprotokollposition, die der letzten festgeschriebenen Transaktion entspricht, im Redo-Header aufgezeichnet. Nachdem der Sicherungssatz erstellt wurde, wird das Binärprotokoll basierend auf dieser Position weiterhin aus der primären Datenbank ausgegeben.

Angenommen, es gibt drei Transaktionen T1, T2 und T3, die mit der Binärprotokolldatei synchronisiert wurden. Die Positionen der drei Transaktionen in der Datei sind jeweils 100, 200 und 300. Auf der Engine-Ebene haben jedoch nur T1 und T3 das Commit abgeschlossen und im Redo-Protokoll aufgezeichnet. Die Position der letzten festgeschriebenen Transaktion T3 ist 300. Zu diesem Zeitpunkt befinden sich die vom Sicherungstool erhaltenen Daten in diesem Zustand. Wenn der Sicherungssatz gestartet wird, wird der Absturzwiederherstellungsprozess befolgt und die Vorbereitungstransaktion wird zurückgesetzt (der Sicherungssatz sichert die Binlog-Datei nicht, was dem leeren XID-Satz im vorherigen Abschnitt entspricht). Seit Punkt 300 wird die Binlog-Synchronisierung von der primären Datenbank fortgesetzt und angewendet, was dazu führt, dass T2 in der Standby-Datenbank verloren geht.

Daher müssen wir einen Mechanismus entwickeln, der sicherstellt, dass die Reihenfolge des Binärprotokollschreibens auf der Serverebene mit der Reihenfolge der Transaktionsübermittlung auf der Speichermodulebene übereinstimmt.

Problem 3: Leistungseinbußen durch gleichzeitiges Schreiben von Redo und Binlog

In Frage 1 wurde erwähnt, dass jede Transaktionsübermittlung Leistungsprobleme verursacht und dieses Problem nach der Einführung von Binlog noch schwerwiegender wird. Jede Transaktionsübermittlung erhöht die Datei-E/A einmal und erfordert eine Datenträgerleerung. Bei einer hohen Systemparallelität werden diese IOs zu einem Engpass, der die Gesamtleistung verlangsamt.

Lösung

Frage 1: Technologie zur Übermittlung von Redo-Log-Gruppen

Die Idee der Redo-Group-Commit-Technologie ist sehr einfach: Durch die Zusammenführung der Flush-Aktionen mehrerer Transaktions-Redo-Logs kann die Anzahl der Flush-Vorgänge reduziert werden. Im Innodb-Protokollsystem hat jedes Redo-Protokoll eine LSN (Log Sequence Number). Wenn eine Transaktion Protokolle in den Redo-Log-Puffer kopiert, erhält sie die aktuelle maximale LSN, und die LSN steigt monoton an. Dadurch wird sichergestellt, dass die LSNs verschiedener Transaktionen nicht wiederholt werden. Nehmen wir dann an, dass die maximalen LSNs der Protokolle der drei Transaktionen Trx1, Trx2 und Trx3 jeweils LSN1, LSN2 und LSN3 sind (LSN1 < LSN2 < LSN3) und sie gleichzeitig festgeschrieben werden. Wenn trx3 zuerst festgeschrieben wird, wird angefordert, die Festplatte auf LSN3 zu leeren, wodurch auch die Redo-Protokolle von Trx1 und Trx2 geleert werden. Trx1 und Trx2 werden feststellen, dass ihre eigenen LSNs kleiner sind als die maximale LSN, die derzeit auf die Festplatte geleert wird, sodass die Festplatte nicht erneut geleert werden muss.

Problem 2: Interne XA-Transaktionen

Wenn Binlog aktiviert ist, werden interne XA-Transaktionen eingeführt, um die obere Schicht und die Speicher-Engine-Schicht zu koordinieren. Insbesondere werden zwei Phasen eingeführt, wenn eine Transaktion festgeschrieben wird:

Vorbereiten: Leert das Redo-Protokoll auf die Festplatte, um sicherzustellen, dass Aktualisierungen an Datenseiten und Undo-Seiten auf die Festplatte geschrieben wurden, und setzt den Transaktionsstatus auf VORBEREITEN;

Commit: 1). Binärprotokoll schreiben und auf die Festplatte schreiben. 2). Die Commit-Schnittstelle für Transaktionen auf Engine-Ebene aufrufen. Setzen Sie den Transaktionsstatus auf COMMIT.

Ein solches zweiphasiges Commit dient hauptsächlich dazu, die Korrektheit bei einem Datenbankabsturz sicherzustellen. Denn sobald das Binärprotokoll auf die Festplatte geschrieben ist, kann es von nachgelagerten Knoten verwendet werden. Solche Transaktionen müssen festgeschrieben und dürfen nach dem Neustart nicht rückgängig gemacht werden. Für Transaktionen, die nicht im Binärprotokoll auf die Festplatte geschrieben wurden, wird bei der Wiederherstellung nach einem Absturz ein Rollback durchgeführt.

Scannen Sie während der Fehlerbehebung insbesondere die letzte Binärprotokolldatei (wenn die Binärprotokollgröße in der Flush-Phase den Schwellenwert überschreitet, rotieren Sie die Binärprotokolldatei, um sicherzustellen, dass die letzte in der Datei aufgezeichnete Transaktion festgeschrieben wurde) und extrahieren Sie die XID daraus. Führen Sie nach dem Prüfpunkt das Redo-Protokoll erneut aus, lesen Sie die Undo-Segmentinformationen der Transaktion, erfassen Sie die Transaktionsliste in der Vorbereitungsphase, vergleichen Sie die XID der Transaktion mit der im Binärprotokoll aufgezeichneten XID und führen Sie ein Commit durch, falls vorhanden. Andernfalls führen Sie ein Rollback durch.

Um sicherzustellen, dass die Schreibreihenfolge des Datenbank-Binlogs mit der Transaktions-Commit-Reihenfolge der InnoDB-Schicht übereinstimmt, verwendet die MySQL-Datenbank vor MySQL 5.6 intern die Sperre prepare_commit_mutex.

Genauer gesagt wird die Sperre während der Vorbereitung der Engine-Ebene für das zweiphasige Commit hinzugefügt und nach dem Commit der Engine-Ebene freigegeben:

innobase_xa_prepare()
write() und fsync() Binärprotokoll
innobase_commit()

Dadurch kann zwar sichergestellt werden, dass die Transaktionsreihenfolge von Binlog und InnoDB konsistent ist, diese Sperre führt jedoch dazu, dass alle Transaktionen seriell ausgeführt werden und jede Übermittlung mindestens mehrere Fsyncs aufruft, was sehr ineffizient ist. Auch dies ist ein Problem, das als nächstes untersucht und gelöst werden muss.

Frage 4

Beziehen Sie sich auf die Redo-Log-Optimierungstechnologie und stellen Sie die Group-Commit-Technologie vor, um die Binlog-Schreibleistung zu optimieren.

Berücksichtigen Sie den Transaktionsübermittlungsprozess, wenn er nicht optimiert ist:

Vorbereiten: In dieser Phase wird das Redo-Log der Speicher-Engine-Schicht (innodb) geleert und der Transaktionsstatus auf VORBEREITET gesetzt (Aktualisierung des Transaktionsstatus auf der Undo-Seite). Binlog ist in dieser Phase nicht involviert.
Commit: Schreiben Sie Binlog-Protokolle und speichern Sie sie auf der Festplatte. Gleichzeitig gibt die Engine-Schicht Sperren frei, gibt Rollback-Segmente frei, setzt den Transaktionsstatus auf COMMITTED und andere sogenannte Group-Commit-Technologien. Im Wesentlichen teilen sie die zeitaufwändigen Commit-Schritte in feinere Schritte auf. Genauer gesagt:

Teilen Sie das Commit von Schritt 2 in drei Phasen auf:

Flush: Binlog schreiben, aber nicht synchronisieren
Sync: Rufen Sie den Vorgang fsync auf, um die Datei auf die Festplatte zu schreiben
Commit: Rufen Sie die Speicher-Engine-Schnittstelle auf, um die Transaktion festzuschreiben

Da das Fsync hier eine zeitaufwändige Operation ist, hoffen wir, genügend Schreibvorgänge anzusammeln, bevor wir einen Fsync-Aufruf tätigen, und verwenden hier die Batch-Technologie. Das Prinzip lautet: Jede Phase in den obigen Schritten verfügt über eine entsprechende Aufgabenverknüpfungsliste, und jeder Thread, der diese Phase betritt, fügt der verknüpften Liste seine eigene Aufgabe hinzu, und die verknüpfte Liste wird gesperrt, um die Richtigkeit sicherzustellen. Der erste Thread, der der verknüpften Liste beitritt, wird zum Leader, und nachfolgende Threads werden zu Followern. Alle Aufgaben in der verknüpften Liste bilden einen Batch, der vom Leader ausgeführt wird, während die Follower einfach darauf warten, dass ihre Aufgaben abgeschlossen werden.

Sobald die Aufgaben der verknüpften Liste einer bestimmten Phase abgeschlossen sind, gelangen diese Aufgaben in die nächste Phase und werden der Aufgaben-verknüpften Liste dieser Phase hinzugefügt, wobei der obige Ausführungsfluss wiederholt wird.

Diese Konstruktion bietet folgende Vorteile:

1. Die Verwendung der Leader-Ausführung anstelle jedes Threads kann die Anzahl der Schreib- / Fsync-Aufrufe effektiv reduzieren und die Effizienz verbessern
2. Dadurch kann sichergestellt werden, dass die Reihenfolge des Schreibens des Transaktions-Binlogs und der Übermittlung auf Engine-Ebene konsistent ist.
3. Mehrere Transaktionen können gleichzeitig ausgeführt werden, ohne dass eine Serialisierung durch die prepare_commit_mutex-Sperre erzwungen wird.
   

Darüber hinaus hat MySQL das Leeren von Redo-Protokollen in der Vorbereitungsphase weiter optimiert. Das ursprüngliche Design ermöglichte das gleichzeitige Leeren von Redo-Protokollen durch mehrere Transaktionen, was jedoch ebenfalls ineffizient war. Das Leeren des Redo-Protokolls in der Vorbereitungsphase kann in der Leerphase der Commit-Phase durchgeführt werden. Es gibt jedoch ein kleines Problem, das erklärt werden muss: Vor der Optimierung ist jeder Thread für das Leeren seines eigenen Redo-Protokolls verantwortlich und kennt die LSN des Redo-Protokolls, das geleert werden muss. Wenn der führende Thread die Redo-Protokolle in der Leerphase auf die Festplatte löscht, kennt er die LSN der Redo-Protokolle jedes Threads nicht. Daher löscht er einfach und grob auf die maximale LSN von log_sys, wodurch sichergestellt wird, dass die Redo-Protokolle der zu übermittelnden Transaktionen auf die Festplatte geleert werden können.

Zusammenfassen

Dies ist das Ende dieses Artikels über Binlog-Optimierungsüberlegungen in MySQL. Weitere relevante Inhalte zu Binlog-Optimierungsüberlegungen in MySQL 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!