Zusammenfassung verschiedener Replikationsmethoden für die MySQL Master-Slave-Replikation

Asynchrone Replikation

Die MySQL-Replikation erfolgt standardmäßig asynchron. Für die Master-Slave-Replikation sind mindestens zwei MySQL-Dienste erforderlich. Diese MySQL-Dienste können auf verschiedene Server oder auf denselben Server verteilt sein.

Die asynchrone MySQL-Master-Slave-Replikation ist das am häufigsten vorkommende Replikationsszenario. Die Integrität der Daten hängt davon ab, dass das BINLOG der Master-Datenbank nicht verloren geht. Solange das BINLOG der Master-Datenbank nicht verloren geht, können wir die verlorenen Daten auch bei einem Absturz der Master-Datenbank manuell über BINLOG mit der Slave-Datenbank synchronisieren.

Hinweis: Wenn die Masterdatenbank ausgefallen ist, kann der DBA manuell über das Tool mysqlbinlog auf das Binärprotokoll der Masterdatenbank zugreifen, die fehlenden Protokolle extrahieren und sie mit der Slavedatenbank synchronisieren. Sie können auch eine hochverfügbare MHA-Architektur konfigurieren, um die fehlenden Daten automatisch zu extrahieren und so die Slavedatenbank zu vervollständigen, oder Global Transaction Identifiers (GTID) aktivieren, um das fehlende Binärprotokoll automatisch in die Slavedatenbank zu extrahieren.

MySQL zeichnet Transaktionen (oder SQL-Anweisungen) in BINLOG auf. Dies bedeutet, dass bei Engines, die Transaktionen unterstützen (wie etwa InnoDB), BINLOG geschrieben werden muss, wenn jede Transaktion festgeschrieben wird. Bei Engines, die keine Transaktionen unterstützen (wie etwa MyISAM), ist BINLOG erforderlich, wenn jede SQL-Anweisung ausgeführt wird. Um die Sicherheit von Binlog zu gewährleisten, führt MySQL den Parameter sync_binlog ein, um die Häufigkeit der BINLOG-Leerung auf die Festplatte zu steuern.

Variablen wie „sync_binlog“ anzeigen; 

• Standardmäßig bedeutet sync_binlog=1, dass MySQL BINLOG auf die Festplatte schreiben muss, bevor eine Transaktion festgeschrieben wird. Auf diese Weise verliert das System selbst dann die meisten Transaktionen im vorbereiteten Zustand, wenn das Betriebssystem des Datenbankhosts abstürzt oder der Host plötzlich die Stromversorgung verliert. Setzen Sie sync_binlog=1, um die Datensicherheit so weit wie möglich zu gewährleisten.
• sync_binlog=0 bedeutet, dass MySQL die Aktualisierung des Binärprotokolls nicht steuert und das Dateisystem selbst die Aktualisierung des Dateicaches steuert.
• sync_binlog=N, wenn N ungleich 0 oder 1 ist, ist die Aktualisierungsmethode ähnlich wie bei sync_binlog=1, mit der Ausnahme, dass die Aktualisierungshäufigkeit auf nach N Binlog-Übermittlungsgruppen erweitert wird.
  

Das Obige ist eine traditionelle asynchrone Replikation. Vor der parallelen Replikationstechnologie (auch als Multithread-Replikation bekannt) von MySQL 5.7 war die Effizienz das am meisten kritisierte Problem. Die Slave-Latenz war ein chronisches Problem. Obwohl es zuvor bereits parallele Replikation auf Schemaebene gab, war der tatsächliche Effekt nicht gut.

Multithread-Replikation

MySQL 5.7 führt eine neue Multithread-Replikationstechnologie ein, die das Problem löst, dass Slaves Daten nicht gleichzeitig anwenden können, wenn sich Daten unter demselben Schema des Masters ändern. Außerdem nutzt es die Vorteile der Binlog-Gruppenübermittlung voll aus und stellt sicher, dass Slaves Relay Log gleichzeitig anwenden können.

In MySQL 8.0 wurde die Multithread-Replikation technisch aktualisiert und das Konzept des Writesets eingeführt. In früheren Versionen wurde beispielsweise zuerst das Update der Tabellendaten A und dann das Update der Tabellendaten B ausgeführt, wenn dieselbe Sitzung der Master-Datenbank nacheinander Transaktionen mehrerer verschiedener verwandter Objekte ausführte. Nachdem BINLOG in die Slave-Datenbank kopiert wurde, können diese beiden Transaktionen nicht parallel ausgeführt werden. Mit dem Einzug des Writesets wird diese Einschränkung aufgehoben.

Verbesserte semisynchrone Replikation

Die oben beschriebene Replikation ist ein asynchroner Vorgang. Es kommt zwangsläufig zu einer gewissen Verzögerung zwischen den Daten der Master- und Slave-Datenbanken. Dies birgt eine versteckte Gefahr: Wenn eine Transaktion in die Master-Datenbank geschrieben und erfolgreich übermittelt wird, die Slave-Datenbank jedoch noch nicht das BINLOG-Protokoll der Master-Datenbank erhalten hat, stürzt die Master-Datenbank aufgrund von Festplattenschäden, Speicherfehlern, Stromausfällen usw. unerwartet ab, was zum Verlust des BINLOG der Transaktion in der Master-Datenbank führt. Zu diesem Zeitpunkt verliert die Slave-Datenbank diese Transaktion, was zu Inkonsistenzen zwischen Master und Slave führt.

Um dieses Problem zu lösen, wurde ab MySQL 5.5 die halbsynchrone Replikation eingeführt. Die Technologie wurde damals vorübergehend als traditionelle halbsynchrone Replikation bezeichnet. Nachdem die Technologie bis MySQL 5.7 weiterentwickelt wurde, entwickelte sie sich zur erweiterten halbsynchronen Replikation (auch verlustfreie Replikation genannt). Bei der asynchronen Replikation kann die Masterdatenbank nach der Ausführung des Commit-Vorgangs und dem Schreiben des BINLOG-Protokolls erfolgreich zum Client zurückkehren, ohne auf die Übertragung des BINLOG-Protokolls an die Slavedatenbank warten zu müssen, wie in der Abbildung dargestellt.

Um bei der halbsynchronen Replikation sicherzustellen, dass jede BINLOG-Transaktion der Master-Datenbank zuverlässig in die Slave-Datenbank repliziert werden kann, gibt die Master-Datenbank dem Front-End-Anwendungsbenutzer nicht jedes Mal sofort eine Rückmeldung, wenn eine Transaktion erfolgreich festgeschrieben wurde. Stattdessen wartet sie, bis mindestens eine Slave-Datenbank (siehe Parameter rpl_semi_sync_master_wait_for_slave_count für Details) ebenfalls die BINLOG-Transaktion empfängt und erfolgreich in das Relay-Protokoll schreibt. Erst dann gibt die Master-Datenbank eine erfolgreiche Festschreibungsoperation an den Client zurück (unabhängig davon, ob es sich um eine herkömmliche halbsynchrone Replikation oder eine erweiterte halbsynchrone Replikation handelt, ist der Zweck derselbe, aber die beiden Methoden unterscheiden sich in einer Hinsicht, was weiter unten erläutert wird).

Durch die halbsynchrone Replikation wird sichergestellt, dass nach dem erfolgreichen Festschreiben einer Transaktion mindestens zwei Protokolldatensätze vorhanden sind, einer im BINLOG-Protokoll der Masterbibliothek und der andere im Relay-Protokoll von mindestens einer Slave-Bibliothek, wodurch die Integrität der Daten weiter gewährleistet wird.

Bei der herkömmlichen halbsynchronen Replikation wartet die Master-Datenbank, nachdem sie Daten in BINLOG geschrieben und den Commit-Vorgang ausgeführt hat, auf die ACK von der Slave-Datenbank. Das heißt, nachdem die Slave-Datenbank das Relay-Protokoll geschrieben und die Daten auf der Festplatte gespeichert hat, gibt sie eine Nachricht an die Master-Datenbank zurück, die die Master-Datenbank darüber informiert, dass sie den Front-End-Anwendungsvorgang erfolgreich zurückgeben kann. Dies führt zu einem Problem, d. h., die Master-Datenbank hat die Transaktion tatsächlich an die Transaktions-Engine-Schicht übergeben, und die Anwendung kann bereits sehen, dass sich die Daten geändert haben, wartet aber nur auf eine Rückgabe. Wenn die Master-Datenbank zu diesem Zeitpunkt abstürzt, ist es möglich, dass die Slave-Datenbank das Relay-Protokoll noch nicht schreiben konnte, was zu Inkonsistenzen zwischen der Master- und der Slave-Datenbank führt. Die verbesserte halbsynchrone Replikation soll dieses Problem lösen. Nachdem die Master-Datenbank Daten in BINLOG geschrieben hat, wartet sie auf die Antwort ACK der Slave-Datenbank, bis mindestens eine Slave-Datenbank in das Relay-Protokoll schreibt und die Daten auf der Festplatte speichert. Anschließend sendet sie eine Nachricht an die Master-Datenbank zurück, die sie darüber informiert, dass sie den Commit-Vorgang ausführen kann. Die Master-Datenbank beginnt dann mit dem Commit an die Transaktions-Engine-Schicht, und die Anwendung kann sehen, dass sich die Daten geändert haben. Der allgemeine Prozess der erweiterten halbsynchronen Replikation wird in der folgenden Abbildung dargestellt.

Wenn im halbsynchronen Replikationsmodus die Slave-Datenbank abstürzt oder es beim Übertragen von BINLOG-Protokollen an die Slave-Datenbank zu einer Netzwerkverzögerung kommt, werden die BINLOG-Protokolle nicht rechtzeitig an die Slave-Datenbank übertragen. Zu diesem Zeitpunkt wartet die Transaktion in der Master-Datenbank eine Zeit lang (die Dauer wird durch die Anzahl der Millisekunden bestimmt, die durch den Parameter rpl_semi_sync_master_timeout festgelegt wird). Wenn BINLOG-Protokolle während dieser Zeit nicht erfolgreich an die Slave-Datenbank gesendet werden können, stellt MySQL die Replikation automatisch auf den asynchronen Modus um und die Transaktion gibt das Übermittlungsergebnis normal an den Client zurück.

Die halbsynchrone Replikation hängt weitgehend von den Netzwerkbedingungen zwischen der Master- und der Slave-Datenbank ab. Je kleiner die Round-Trip-Verzögerung RTT ist, desto besser ist die Echtzeitleistung der Slave-Datenbank. Einfach ausgedrückt: Je schneller das Netzwerk zwischen der Master- und der Slave-Datenbank ist, desto Echtzeit-fähiger sind die Slave-Datenbanken.

Hinweis: Die Round-Trip-Time (RTT) ist ein wichtiger Leistungsindikator in Computernetzwerken. Sie gibt die Gesamtzeit vom Beginn der Datenübertragung bis zum Erhalt der Bestätigung vom Empfänger an (das kann etwas verwirrend sein, wir können es als die ersten beiden Handshakes des TCP-Drei-Wege-Handshakes verstehen).

Zusammenfassen

Dies ist das Ende dieses Artikels über die MySQL-Master-Slave-Replikation. Weitere Informationen zur MySQL-Master-Slave-Replikation finden Sie in früheren Artikeln auf 123WORDPRESS.COM oder in den folgenden verwandten Artikeln. Ich hoffe, Sie werden 123WORDPRESS.COM auch in Zukunft unterstützen!