Umfassende Analyse des MySql-Master-Slave-Replikationsmechanismus

Als relationale Datenbank verfügt MySQL über einen integrierten Datenreplikationsmechanismus, der die Implementierung erweiterter Funktionen wie einer Hochverfügbarkeitsarchitektur auf Grundlage des Replikationsmechanismus ermöglicht. Dadurch ist MySQL für Produktionsumgebungen geeignet, ohne dass zusätzliche Plug-Ins oder andere Tools erforderlich sind. Dies ist eine der Voraussetzungen für die breite Nutzung von MySQL in der Praxis.

Der auf MySQL basierende Replikationsmechanismus kann nicht nur eine hohe Verfügbarkeit der Datenbank erreichen, sondern auch erweiterte Funktionen wie Leistungssteigerung, externe Notfallwiederherstellung und Heiß-Kalt-Trennung realisieren.

• Hohe Verfügbarkeit: Durch die Konfiguration eines bestimmten Replikationsmechanismus implementiert MySQL eine hostübergreifende Datenreplikation und erreicht so ein gewisses Maß an Hochverfügbarkeit. Wenn Sie eine höhere Verfügbarkeit erreichen müssen, müssen Sie nur mehrere Kopien konfigurieren oder eine kaskadierende Replikation durchführen, um das Ziel zu erreichen.
• Leistungssteigerung: Da der Replikationsmechanismus mehrere Datensicherungen bereitstellt, können Sie in Szenarien mit geringen Anforderungen an die Lese-/Schreibkonsistenz ein oder mehrere Replikate konfigurieren, um Leseaufträge an Replikatknoten zu verteilen und so die allgemeine Lese-/Schreibleistung zu verbessern.
• Offsite-Notfallwiederherstellung: Sie müssen den Replikationsknoten nur in einem externen Computerraum bereitstellen, um problemlos eine bestimmte Offsite-Notfallwiederherstellungsfunktion zu erhalten. In der Praxis müssen Faktoren wie die Netzwerklatenz berücksichtigt werden, die die Gesamtleistung beeinträchtigen können.
• Trennung von Transaktionen: Durch die Konfiguration eines Replikationsmechanismus und das Senden von Transaktionen mit niedriger Frequenz und hohem Rechenaufwand zur Ausführung an Replikationsknoten kann verhindert werden, dass diese Transaktionen mit Transaktionen mit hoher Frequenz um Rechenressourcen konkurrieren. Dadurch können allgemeine Leistungsprobleme vermieden werden.

Um die oben genannten Funktionen zu erhalten, müssen Sie den grundlegenden MySQL-Replikationsmechanismus verstehen und basierend auf dem tatsächlichen Anwendungsszenario die geeignete Konfiguration auswählen.

Master-Slave-Replikationsmechanismus

MySQL implementiert eine Master-Slave-Replikation basierend auf Binlog. Der Slave-Knoten verfolgt und erhält die neuesten Updates im Binlog des Master-Knotens und spielt sie in sich selbst wieder ab, wodurch die Daten des Master-Knotens repliziert werden.

Die folgende Abbildung ist ein schematisches Diagramm des MySQL-Master-Slave-Replikationsprozesses. Am gesamten Prozess sind drei Threads beteiligt. Ihre Aufgaben lauten wie folgt:

• Binärprotokoll-Dump-Thread des Masterknotens: Dieser Thread wird erstellt, nachdem der Slaveknoten eine Verbindung mit dem Masterknoten hergestellt hat, und ist dafür verantwortlich, die neu geschriebenen Daten im Binärprotokoll an den Slaveknoten zu senden. Beim Lesen des Binlogs erwirbt der Dump-Thread zuerst die Binlog-Sperre, gibt sie unmittelbar nach dem Lesen frei und sendet dann die gelesenen Daten an den Slave-Knoten.
• E/A-Thread des Slave-Knotens: Der E/A-Thread des Slave-Knotens ist für das Senden von Datensynchronisierungsanforderungen an den Master-Knoten, den Empfang von vom Master-Knoten gesendeten Daten und das Schreiben dieser in das Relay-Protokoll verantwortlich.
• SQL-Thread des Slave-Knotens: Dieser Thread liest Datenaktualisierungen aus dem Relay-Protokoll und spielt sie erneut ab.

Asynchrone Replikation

Standardmäßig ist die Master-Slave-Replikation von MySQL eine asynchrone Replikation. Bei diesem Mechanismus antwortet der Masterknoten unmittelbar nach Abschluss des lokalen Protokollschreibens auf die Anforderung des Clients, und der Datenreplikationsprozess des Slaveknotens wird asynchron ausgeführt.

Da der Replikationsprozess bei diesem Mechanismus die Antwort des primären Knotens auf Clientanforderungen nicht beeinflusst, kommt es im Vergleich zu einem einzelnen Knoten offensichtlich zu keinem signifikanten Verlust der Gesamtleistung.

Wenn jedoch bei diesem Mechanismus der Masterknoten abstürzt, während die Daten festgeschrieben, aber nicht mit dem Slaveknoten synchronisiert werden, und ein Master-Slave-Wechsel erfolgt und neue Daten geschrieben werden, kann es zu Datenverlust oder Inkonsistenzen kommen.

Halbsynchrone Replikation

Ab Version 5.6 unterstützt MySQL die halbsynchrone Replikation, die im Vergleich zur asynchronen Replikation folgende Unterschiede aufweist:

Nach Erhalt der Clientanforderung muss der Masterknoten das Schreiben des Protokolls seines eigenen Knotens abschließen und warten, bis mindestens ein Slaveknoten die Datensynchronisierungsantwort abgeschlossen hat (oder eine Zeitüberschreitung auftritt), bevor er auf die Anforderung antwortet.

Der Slave-Knoten antwortet dem Master-Knoten erst, nachdem er in das Relay-Protokoll geschrieben und die Datenträgerbereinigung abgeschlossen hat.

Wenn der Slave-Knoten auf ein Timeout reagiert, degeneriert der Master-Knoten den Synchronisierungsmechanismus auf asynchrone Replikation. Nachdem mindestens ein Slave-Knoten wiederhergestellt ist und den Datenaufholvorgang abgeschlossen hat, stellt der Master-Knoten den Synchronisierungsmechanismus auf halbsynchrone Replikation wieder her.

Es ist ersichtlich, dass die halbsynchrone Replikation im Vergleich zur asynchronen Replikation die Datenverfügbarkeit bis zu einem gewissen Grad verbessert. Wenn sie nicht zur asynchronen Replikation degeneriert ist, werden die Daten bei einem Ausfall des Masterknotens auf mindestens einen Slaveknoten kopiert.

Da der Slave-Knoten gleichzeitig die Antwort an den Client abschließen muss, ist im Vergleich zur asynchronen Replikation mehr Zeit für die Netzwerkinteraktion zwischen Master- und Slave-Knoten erforderlich und der Slave-Knoten benötigt mehr Zeit, um Dateien zu schreiben und auf die Festplatte zu übertragen. Daher wird die Antwortleistung des gesamten Clusters an den Client zwangsläufig reduziert.

Master-Slave-Replikationsformat

Da der Replikationsmechanismus von MySQL auf Binlog basiert, bestimmt das Format von Binlog das Format der Master-Slave-Replikation. Es gibt zwei Arten von Binärprotokollen: zeilenbasiert und anweisungsbasiert. Daher gibt es für die Replikation auch zwei entsprechende Formate.

Anweisungsbasierte Replikation (SBR)

Bei der anweisungsbasierten Replikation zeichnet das Binärprotokoll nur die ausgeführten Anweisungen auf. Diese Methode bietet folgende Vorteile:

• Es existiert seit der Version 3.23 und ist eine seit langem bewährte Technologie.
• Es werden weniger Daten in die Protokolldatei geschrieben. Dies bedeutet einen geringeren Dateischreib- und Netzwerkübertragungsverbrauch, sodass die Master-Slave-Replikation insgesamt schneller abgeschlossen werden kann und die Leistung verbessert wird.
• Die Protokolldatei zeichnet alle in der Datenbank ausgeführten Anweisungen auf und kann zu Prüf- und anderen Zwecken verwendet werden.
  

Es gibt folgende Nachteile:

• Benutzerdefinierte Funktionen (UDFs) und Funktionen, deren Ausführungsergebnis ungewiss ist, können nicht kopiert werden.
• Beim Aktualisieren von Daten sind mehr Zeilensperren erforderlich als bei der zeilenbasierten Replikation
• Bei komplexen Anweisungen wie „Erst einfügen und dann aktualisieren“ muss der Slave-Knoten eine vollständige entsprechende Wiedergabe durchführen, während bei der zeilenbasierten Replikation nur das Endergebnis ausgeführt werden muss.
  

Zeilenbasierte Replikation (RBR)

Beim zeilenbasierten Replikationsmechanismus ist das entsprechende Binärprotokoll ebenfalls zeilenbasiert. In diesem Fall werden bei jeder Aktualisierung und beim Schreiben von Daten in das Binärprotokoll Änderungen in allen betroffenen Zeilen konvertiert.

Diese Replikationsmethode bietet folgende Vorteile:

• Alle Datenänderungen können sicher repliziert werden und werden nicht von UDFs und Sonderfunktionen beeinflusst.
• Die meisten DBMS verwenden diese Replikationsmethode und die Kosten der Wissensmigration sind gering.
• Beim Aktualisieren von Daten sind weniger Zeilensperren erforderlich, was zu einer höheren Leistung führt.
  

Es gibt folgende Nachteile:

• Wenn DML große Datenmengen umfasst, erzeugen zeilenbasierte Protokolle eine große Menge an Protokolldaten. Große Datenmengen bedeuten mehr Zeit für das Schreiben von Protokolldateien und die Netzwerkübertragung, was zu einer erheblichen Verschlechterung der Gesamtleistung führen und auch Parallelitätsprobleme verursachen kann.
• Es ist nicht möglich, die ausgeführten Anweisungen über das Protokoll anzuzeigen, und es ist auch nicht möglich, die auf dem Slave-Knoten ausgeführten Anweisungen zu kennen.
  

Bei tatsächlichen Architekturanwendungen muss der Master-Slave-Replikationsmechanismus entsprechend den Geschäftsmerkmalen des Systems sinnvoll eingesetzt und das geeignete Master-Slave-Replikationsformat ausgewählt werden.

Das Obige ist der detaillierte Inhalt der umfassenden Analyse des MySql-Master-Slave-Replikationsmechanismus. Weitere Informationen zum MySql-Master-Slave-Replikationsmechanismus finden Sie in den anderen verwandten Artikeln auf 123WORDPRESS.COM!