Lösung für das MySQL Master-Slave-Verzögerungsproblem

Heute werden wir uns ansehen, warum es zu Master-Slave-Verzögerungen kommt und wie man damit umgeht.

Lehnen Sie sich zurück und machen Sie sich bereit!

Gemeinsame Master-Slave-Architektur

Angesichts der steigenden Zahl von Besuchen reichte die Antwortkapazität einer einzelnen Datenbank nicht mehr aus. Daher wurde eine Master-Slave-Architektur abgeleitet, die Lesen und Schreiben trennt, bei der die Master-Datenbank Daten schreibt und die Slave-Datenbank Daten liest.

In der Produktionsumgebung gibt es viele gängige Master-Slave-Architekturen. Hier sind einige gängige Architekturmuster.

Master-Slave-Replikationsprinzip

Nachdem wir die grundlegende Architektur und die zugehörige Master-Slave-Konfiguration verstanden haben, kommen wir zum Punkt.

Bei der Master-Slave-Beziehung besteht der übliche Vorgang darin, dass die Master-Datenbank zum Schreiben von Daten und die Slave-Datenbank zum Lesen von Daten verwendet wird. Dies hat den Vorteil, dass der Lese- und Schreibdruck verteilt wird und vermieden wird, dass alle Anfragen an die Hauptdatenbank gestellt werden. Gleichzeitig wurde die Skalierbarkeit und Belastbarkeit des Systems durch die horizontale Erweiterung der Datenbank deutlich verbessert.

Es tritt jedoch ein Problem auf. Um die Daten in der Slave-Datenbank mit der Master-Datenbank konsistent zu halten, müssen die Daten in der Master-Datenbank nach dem Schreiben mit der Slave-Datenbank synchronisiert werden. Wie kann die Datenkonsistenz zwischen der Master-Datenbank und der Slave-Datenbank aufrechterhalten werden und wie synchronisiert die Master-Datenbank Daten in Echtzeit mit der Slave-Datenbank?

Begründung

Es gibt zwei sehr wichtige Protokolldateien bei der MySQL Master-Slave-Replikation:

• binlog (binäre Logdatei)
• Relay-Protokoll

Während des Master-Slave-Synchronisierungsprozesses zeichnet die Master-Datenbank alle Betriebsereignisse im Binlog auf. Die Slave-Datenbank hält die Kommunikation mit der Master-Datenbank aufrecht, indem sie einen E/A-Thread öffnet und erkennt, ob sich die Binlog-Protokolldatei in einem bestimmten Zeitintervall geändert hat. Wenn sich das Binlog-Protokoll ändert, generiert die Master-Bibliothek einen Binlog-Dump-Thread, um das Binlog an den E/A-Thread der Slave-Bibliothek zu übertragen. Der E/A-Thread auf dem Slave kopiert das Binärprotokoll in sein eigenes Relay-Protokoll. Schließlich liest der SQL-Thread in der Slave-Datenbank die Ereignisse im Relay-Protokoll und spielt sie erneut in die Slave-Datenbank ab.

Ursachen für Master-Slave-Verzögerung

Wir kennen den relevanten Prozess der Master-Slave-Replikation im obigen Prozess bereits, aber wenn die Master-Datenbank aktualisiert wird, wird die Slave-Datenbank synchronisiert. Warum tritt also die Master-Slave-Verzögerung auf?

Zufällige Wiedergabe

Der Vorgang zum Schreiben des Binlogs in die MySQL-Hauptdatenbank wird sequentiell geschrieben. Wie bereits erwähnt, ist die sequentielle Lese- und Schreibgeschwindigkeit der Festplatte sehr schnell. Ebenso sind die Geschwindigkeit und Effizienz der Ausführung von Protokollen aus dem E/A-Thread in der Bibliothek sehr hoch. Vergessen Sie jedoch nicht, dass es auch einen SQL-Thread zum Wiedergeben der Daten gibt und dass der Wiedergabevorgang aus zufälligen Schreibvorgängen auf die Festplatte besteht. Sie sollten jetzt verstehen, dass die Daten im Relay-Protokoll zu einem bestimmten Zeitpunkt nicht mehr in die Slave-Datenbank wiedergegeben werden können, was zu einer Master-Slave-Verzögerung führt.

Hohe Parallelität der Hauptdatenbank

Wenn man den Wiedergabestatus des SQL-Threads in der Slave-Datenbank kennt, ist es nicht schwer zu verstehen, warum die hohe Parallelität der Master-Datenbank die Master-Slave-Verzögerung verursacht. Zu einem bestimmten Zeitpunkt werden eine große Anzahl von Schreibanforderungen an die Master-Datenbank gesendet, was bedeutet, dass Binlog kontinuierlich geschrieben werden muss. Zu diesem Zeitpunkt wird der SQL-Thread in der Slave-Datenbank überlastet und es kommt natürlich zu einer Master-Slave-Verzögerung.

Warten auf Sperre

Wenn bei einer Single-Thread-SQL-Anweisung eine Blockierung auftritt, wartet die Anweisung, bis die Ausführung erfolgreich war, bevor sie fortgesetzt wird. Wenn die Slave-Datenbank zu einem bestimmten Zeitpunkt aufgrund einer Abfrage in eine Sperrwartesituation gerät, wird der nächste Vorgang erst ausgeführt, nachdem der aktuelle Vorgang abgeschlossen ist. Ebenso tritt eine Master-Slave-Verzögerung auf.

Master-Slave-Verzögerungsverarbeitung

Nachdem wir nun die Ursache der Master-Slave-Verzögerung kennen, sehen wir uns an, wie wir damit umgehen können.

Parallele Replikation

Können wir die Multithread-Wiedergabe verwenden, da die Geschwindigkeit der SQL-Einzelthread-Wiedergabe begrenzt ist? MySQL Version 5.6 und höher bietet eine parallele Replikationsmethode, die den SQL-Thread zur Wiedergabe in mehrere Arbeitsthreads konvertiert und so das Master-Slave-Verzögerungsproblem löst.

Reduzieren Sie die Parallelität der Hauptdatenbank

Sie sagen vielleicht: „Ich verwende derzeit eine ältere Version der Datenbank und kann die Version nicht aktualisieren. Was soll ich also tun?“ In Situationen, in denen die Masterdatenbank eine hohe Parallelität aufweist, können Sie die Verzögerung nur beheben, indem Sie die Parallelität auf diese Weise steuern. Verwenden Sie Redis häufiger.

Lesen Sie die Hauptbibliothek

Diese Situation kennen Sie bestimmt. Manche Daten mit hohen Echtzeitanforderungen können Sie nicht einfach aus der Datenbank auslesen. Wenn es zu einer Verzögerung von einem halben Tag kommt, müssen Sie einen Beitrag zu Ihrem Jahresendbonus leisten.

Zusammenfassen

Master-Slave-Replikationsprinzip

Es gibt zwei sehr wichtige Protokolldateien bei der Master-Slave-Replikation, Binlog und Relay-Log, die sich jeweils in der Master- und der Slave-Bibliothek befinden. Binlog ist die Grundlage der Master-Slave-Replikation. Betriebsereignisse werden in Binlog geschrieben und zur Synchronisierung über E/A-Threads an die Slave-Datenbank übertragen.

Ursachen für Master-Slave-Verzögerung

• Der Wiedergabevorgang des SQL-Threads in der Slave-Datenbank wird zufällig auf die Festplatte geschrieben, und der SQL-Thread ist ein Single-Thread. Wenn die Daten also nicht rechtzeitig wiedergegeben werden können, führt dies zu Master-Slave-Verzögerungen.
• Eine hohe Parallelität der Masterdatenbank führt dazu, dass Schreibvorgänge kontinuierlich in das Binärprotokoll geschrieben werden, was den SQL-Thread überlasten und zu Master-Slave-Verzögerungen führen kann.
• Auch das Warten auf die Sperre während der Wiedergabe ist einer der Gründe für die Verzögerung.

Master-Slave-Verzögerungsverarbeitung

MySQL Version 5.6 und höher verwendet parallele Replikation, um das durch SQL Single-Thread verursachte Master-Slave-Verzögerungsproblem zu lösen. Bei niedrigeren Versionen kann dieses Problem durch Reduzierung der Parallelität der Hauptbibliothek gelöst werden. Wenn die Echtzeitanforderungen an die Daten streng sind, können Sie dieses Ziel durch Lesen der Hauptdatenbank erreichen.

Oben finden Sie detaillierte Informationen zur Lösung des MySQL-Master-Slave-Verzögerungsproblems. Weitere Informationen zur MySQL-Master-Slave-Verzögerung finden Sie in den anderen verwandten Artikeln auf 123WORDPRESS.COM!