Ursachen und Lösungen für Verzögerungen bei der MySQL-Master-Slave-Synchronisierung

Aus historischen Gründen basiert die MySQL-Replikation auf dem logischen Binärprotokoll und nicht auf dem Redo-Protokoll. Ich wurde oft gefragt, wann MySQL die physikalische Replikation unterstützen wird. Tatsächlich hängt es von den Ideen der MySQL-Chefs ab. Als ich das letzte Mal mit Professor Lai ein Brainstorming machte, fragte ich plötzlich: Wird MySQL eine Redo-Replikation basierend auf Paxos haben?

Der eigentliche Vorteil der physischen Replikation liegt nicht in der Korrektheit, da die auf dem ROW-Format basierende Protokollreplikation die Korrektheit der Replikation vollständig garantieren kann. Weil das physische Protokoll während der Transaktionsausführung kontinuierlich geschrieben wird und das Binärprotokoll nur geschrieben wird, wenn die Transaktion festgeschrieben wird. Die Vorteile der physischen Protokollierung liegen daher in folgenden Punkten:

• Unter der Replikationsarchitektur werden große Transaktionsprotokolle schnell festgeschrieben.
• Bei der Replikationsarchitektur ist die Master-Slave-Datenverzögerung gering.

Angenommen, eine große Transaktion wird eine Stunde lang ausgeführt. Beim letzten Commit muss nur das Redo-Protokoll des zuletzt übermittelten Teils geschrieben werden (das Redo-Protokoll kann als physisches Protokoll betrachtet werden). Obwohl die Gesamtmenge des für diese große Transaktion geschriebenen Redo-Protokolls 1 G betragen kann, muss die Master-Slave-Replikation der Daten zum Zeitpunkt der Übermittlung nur den letzten Teil des Protokolls an den Remote-Slave übertragen, da das vorherige Redo-Protokoll innerhalb von 1 Stunde nach der Ausführung kontinuierlich mit dem Slave synchronisiert wurde.

Bei Binärprotokollen gilt: Da der Schreibzeitpunkt beim Festschreiben der Transaktion liegt, muss die Festschreibzeit der Transaktion unter der Annahme, dass ein 1G-Binärprotokoll generiert wird, die Schreibzeit dieses 1G-Protokolls umfassen. Bei Oracle gibt es eine Redensart, die besagt, dass die Transaktions-Commit-Geschwindigkeit unabhängig von der Größe der Transaktion gleich bleibt. Dies trifft auf die MySQL-Datenbank nicht zu. Das heißt, die Commit-Geschwindigkeit von MySQL hängt von der Größe des von der Transaktion generierten Binärprotokolls ab und die Commit-Geschwindigkeit der Transaktion ist nicht flach.

Noch schlimmer ist, dass die MySQL-Master-Slave-Replikation bei großen Transaktionen verzögert wird. Angenommen, eine große Transaktion wird 1 Stunde lang auf dem Master-Server ausgeführt, muss sie zum letzten Commit-Zeitpunkt an den Slave-Server übertragen werden. Die Master-Slave-Verzögerung beträgt mindestens 1 Stunde. Wenn die Ausführung des Slave-Servers eine weitere Stunde dauert, kann die Verzögerung der Master-Slave-Replikation im schlimmsten Fall 2 Stunden betragen. Für die physische Replikation gibt es keine solche Einschränkung. Der Grund ist wie oben erwähnt. Während des Transaktionsübermittlungsprozesses wird das Protokoll bereits übertragen und wiedergegeben.

Obwohl die physische Replikation gut ist, hat sie auch ihre Nachteile. Aus meiner eigenen Erfahrung:

• Bei der physischen Replikation führt ein fehlerhafter Block auf dem Host dazu, dass sowohl der Master- als auch der Slave-Server nicht gestartet werden können. Ich glaube, dass viele Studenten auf dieses Problem gestoßen sind.
• Darüber hinaus ist die Durchführung von ETL schwierig. Wie lassen sich beispielsweise physische Protokolle mit der Hadoop-Big-Data-Plattform synchronisieren?

Kurz gesagt: Für die MySQL-Datenbank dürfen zu keinem Zeitpunkt große Transaktionen ausgeführt werden. Wenn Sie sie ausführen möchten, teilen Sie die große Transaktion zur Ausführung in kleine Untertransaktionen auf. Dies ist das grundlegendste Mantra, es unterscheidet sich jedoch stark von Oracle. Kurz gesagt, es gibt in der Qi-Sekte und der Schwert-Sekte kein Gut oder Böse. Nur wenn man lernt, die Unterschiede zwischen ihnen zu verstehen und sie zu integrieren, kann man den ultimativen Zustand wie Feng Qingyang erreichen.

MySQL verwendet die Master-Slave-Synchronisierungsmethode, um Lese- und Schreibvorgänge zu trennen, was den Druck auf den Masterserver verringert und in der Branche mittlerweile weit verbreitet ist. Durch die Master-Slave-Synchronisation kann grundsätzlich eine Echtzeitsynchronisation erreicht werden. Ich habe das Master-Slave-Synchronisierungsschema von einer anderen Website übernommen.

Nachdem die Konfiguration abgeschlossen und die Master-Slave-Synchronisierung abgeschlossen ist, schreibt der Master-Server die Aktualisierungsanweisungen in das Binärprotokoll, und der IO-Thread des Slave-Servers (beachten Sie, dass es vor 5.6.3 nur einen IO-Thread gibt und nach 5.6.3 mehrere Threads zum Lesen vorhanden sind, sodass die Geschwindigkeit natürlich höher ist) geht zurück, um das Binärprotokoll des Master-Servers zu lesen und es in das Relay-Protokoll des Slave-Servers zu schreiben. Anschließend führt der SQL-Thread des Slave-Servers die SQL-Anweisungen im Relay-Protokoll nacheinander aus, um die Daten wiederherzustellen.

Staffellauf bedeutet weitergeben, und Staffellauf bedeutet Staffellauf.

1. Ursachen für Verzögerungen bei der Master-Slave-Synchronisation

Wir wissen, dass ein Server N Links öffnet, mit denen sich Clients verbinden können, sodass große gleichzeitige Aktualisierungsvorgänge stattfinden, aber nur ein Thread das Binärprotokoll vom Server liest. Wenn ein bestimmtes SQL über einen längeren Zeitraum auf dem Slave-Server ausgeführt wird oder ein bestimmtes SQL die Tabelle sperren muss, wird eine große Menge an SQL auf dem Master-Server angesammelt und nicht mit dem Slave-Server synchronisiert. Dies führt zu einer Master-Slave-Inkonsistenz, d. h. einer Master-Slave-Verzögerung.

2. Lösung für die Verzögerung der Master-Slave-Synchronisierung

Tatsächlich gibt es keine Universallösung für die Verzögerung der Master-Slave-Synchronisierung, da alle SQL-Anweisungen einmal auf dem Slave-Server ausgeführt werden müssen. Wenn der Master-Server jedoch kontinuierlich aktualisiert und geschrieben wird, steigt die Wahrscheinlichkeit, dass sich die Verzögerung erhöht, sobald eine Verzögerung auftritt. Natürlich können wir einige mildernde Maßnahmen ergreifen.

• a. Wir wissen, dass der Master-Server, da er für Aktualisierungsvorgänge verantwortlich ist, höhere Sicherheitsanforderungen hat als der Slave-Server. Daher können einige Einstellungen geändert werden, z. B. sync_binlog = 1, innodb_flush_log_at_trx_commit = 1 und andere Einstellungen. Der Slave benötigt jedoch keine so hohe Datensicherheit. Sie können sync_binlog auf 0 setzen oder binlog ausschalten. innodb_flushlog, innodb_flush_log_at_trx_commit können auch auf 0 gesetzt werden, um die Ausführungseffizienz von SQL zu verbessern, was die Effizienz erheblich steigern kann. Eine weitere Möglichkeit besteht darin, als Slave bessere Hardware als die Master-Datenbank zu verwenden.
• b. Das heißt, verwenden Sie einen Slave-Server als Backup, anstatt Abfragen bereitzustellen. Die Belastung dort wird reduziert und die Effizienz der Ausführung des SQL im Relay-Protokoll ist natürlich hoch.
• c. Fügen Sie Slave-Server hinzu. Dies dient dazu, den Lesedruck zu verteilen und so die Serverlast zu reduzieren.

3. Methoden zur Bestimmung der Master-Slave-Verzögerung

MySQL bietet einen Befehl zum Anzeigen des Slave-Serverstatus, der über „show slave status“ angezeigt werden kann. Sie können beispielsweise den Wert des Parameters Seconds_Behind_Master überprüfen, um festzustellen, ob eine Master-Slave-Verzögerung vorliegt.

Die Werte lauten wie folgt:

NULL – Zeigt an, dass entweder io_thread oder sql_thread fehlgeschlagen ist, d. h., der Ausführungsstatus des Threads ist „Nein“ und nicht „Ja“.
0 - Dieser Wert ist Null, was wir am meisten sehen möchten, da er anzeigt, dass der Master-Slave-Replikationsstatus normal ist

Andere Methoden habe ich nicht ausprobiert, daher werde ich dazu vorerst nichts sagen.

Zusammenfassen

Das Obige ist der vollständige Inhalt dieses Artikels. Ich hoffe, dass der Inhalt dieses Artikels einen gewissen Lernwert für Ihr Studium oder Ihre Arbeit hat. Vielen Dank für Ihre Unterstützung von 123WORDPRESS.COM. Wenn Sie mehr darüber erfahren möchten, schauen Sie sich bitte die folgenden Links an