Dieser Artikel zeigt Ihnen das Prinzip der MySQL Master-Slave-Synchronisation

Kurze Analyse des MySQL-Master-Slave-Synchronisationsprinzips

Bevor wir mit der Erläuterung der Prinzipien beginnen, fassen wir zunächst das Wissen zusammen.
Was ist Master-Slave, warum brauchen wir Master-Slave, wie können wir Master-Slave implementieren, das Prinzip der MySQL-Master-Slave-Synchronisation

1. Was ist Master-Slave?

Tatsächlich ist das Konzept von Master-Slave sehr einfach. Der Host ist der Dienst, den wir normalerweise zum Lesen und Schreiben verwenden. Wir nennen ihn Master.
Ein Slave ist eine Erweiterung des Hosts. Er wird normalerweise nicht zum Lesen und Schreiben verwendet. Wir nennen ihn einen Slave.
Die Daten auf dem Slave werden in irgendeiner Form vom Host abgerufen und auf den Slave geschrieben. Theoretisch kann der Slave keine Daten direkt von der Außenwelt abrufen.

2. Warum brauchen wir eine Herr-Sklave-Beziehung?

Das erste Master-Slave-System war ein Master-Slave-System, d. h. der Master ist die Hauptmaschine und der Slave die Backup-Maschine. Weil das Datenvolumen und die Parallelität früherer Software nicht hoch waren. Der Host kann die tägliche Nutzung vollständig unterstützen.
Daher wird die hohe Verfügbarkeit der Datenbank durch den Master-Slave-Modus gewährleistet. Wenn ein Ausfall der Masterdatenbank erkannt wird, wird die Datenquelle des Dienstes automatisch auf die Backup-Datenbank umgeschaltet.
Im Zuge der Geschäftsentwicklung stellten wir fest, dass ein einzelner Master den Geschäftsanforderungen oft nicht gerecht wurde. Daher begannen wir mit der Erweiterung des traditionellen Master-Slave-Systems.

(1) Ein Master und ein Slave. Der Slave dient nicht nur als Backup-Maschine, sondern auch als Datenbank zum Lesen von Datenquellen. Wenn der Geschäftsdienst Daten schreibt, schreibt er sie auf die Master-Maschine, und wenn er Daten liest, liest er sie von der Slave-Maschine. Dadurch wird der Druck auf den Host verringert (2) Ein Master und mehrere Slaves. Nachdem der Master geschrieben und der Slave gelesen hat, haben wir festgestellt, dass ein einzelner Slave-Knoten bei der Unterstützung von Geschäftsabfragedaten immer noch einen Leistungsengpass aufweist. Daher werden wir den Slave horizontal erweitern, um mehrere Slaves zu erreichen.
(3) Doppel-M
Der Slave wird zum Master befördert, und die beiden Master sind jeweils Slaves voneinander und teilen sich den Lese- und Schreibdruck. (4) Kaskadenreplikation Die Kaskadenreplikation ähnelt einem Master und mehreren Slaves. Der Unterschied besteht darin, dass die Datenquelle des sekundären Slaves vom Slave und nicht vom Master stammt. Dies liegt hauptsächlich daran, dass sich synchronisierte Daten nach einer Erhöhung der Anzahl der Slaves negativ auf die Leistung des Hosts auswirken. (5) Mehrere Master und ein Slave. In Szenarien mit mehr Schreibvorgängen und weniger Lesevorgängen werden mehrere Master verwendet, um den Druck auf den Host zu verringern, während ein Slave zum Abschließen des Lesevorgangs und der Datensicherung verwendet wird.

3. Wie erreicht man eine Master-Slave-Synchronisation?

Denken Sie nicht, dass die Master-Slave-Synchronisierung zu schwer zu verstehen ist. Tatsächlich ist sie ganz einfach. Als Softwareentwickler müssen Sie lediglich Code schreiben, Daten aus der Masterdatenbank suchen, eine Verbindung zur Sicherungsdatenbank herstellen und die Daten dort hineinschreiben können. Dies ist die am einfachsten zu verstehende Master-Slave-Synchronisierung.
Da diese Methode jedoch zu grob ist und eine schlechte Leistung aufweist, verfügt MySQL selbst über einen vollständigen Master-Slave-Synchronisierungsmechanismus, um sicherzustellen, dass Daten effizient vom Host zum Slave synchronisiert werden können.
Neben MySQLs eigener Master-Slave-Synchronisation gibt es in der Branche auch einige Komponenten, die diese unterstützen, wie etwa Alibabas Kanal. Dies dient hauptsächlich einer flexibleren Datensynchronisation, wie etwa dem Parsen der synchronisierten Daten. Die synchronisierte Slave-Maschine muss nicht mehr MySQL verwenden, sondern andere Speicherdienste.

4. Das Prinzip der MySQL-Master-Slave-Synchronisation

MySQL selbst implementiert die Master-Slave-Synchronisierung, hauptsächlich unter Verwendung von Binlog-Protokollen.
Da es nicht der Schwerpunkt dieses Artikels ist, hier eine kurze Beschreibung des Binlog-Protokolls:
Es handelt sich um ein Protokoll, das von MySQL zum Aufzeichnen von Datenbankänderungen verwendet wird.
Beispielsweise wird der Wert eines Datums von 0 auf 1 geändert (DML-Anweisung).
Beispielsweise wird eine Tabelle gelöscht (DDL-Anweisung)
Es gibt drei Formen von Binlog:
(1) Anweisung: Zeichnet die konkrete Operationsanweisung auf, die die Änderung verursacht hat, z. B. „xxxxx einfügen…“.
(2) Zeile: basierend auf Datenzeilen. Der ursprüngliche Datenzeilenwert wird von xx in yy geändert. Dieser Typ von Datenzeilen nimmt normalerweise mehr Platz ein.
(3) mixed: Gemischter Modus, der Dienst entscheidet selbst, welche Form die Änderung annimmt.
Wenn der SQL-Vorgang in das Binärprotokoll geschrieben wird, wird davon ausgegangen, dass die SQL-Ausführung erfolgreich war, anstatt auf die entsprechende Festplatte geschrieben zu werden (Festplatte leeren). Daher können wir den entsprechenden Wert in Binlog als eine Zuordnung von MySQL verstehen. Das Synchronisieren von MySQL-Daten unterscheidet sich vom Synchronisieren der Daten auf der Festplatte, es muss jedoch nur das Binlog-Protokoll synchronisiert werden.
Das spezifische Synchronisationsprinzip ist wie folgt:
(1) Nachdem die Master-Slave-Synchronisierung eingerichtet wurde (nachdem relevante Vorgänge wie IP, Port, Service-ID usw. eingerichtet wurden)
(2) Die relevanten Änderungen werden in das Binlog geschrieben. (3) Der Master startet einen Thread: den Binlog-Dumplog-Thread. Dieser Thread benachrichtigt den Slave über eine SQL-Änderung und sendet die Binlog-Änderungen an den Slave. (4) Nachdem der Slave die Anforderung empfangen hat, startet er einen Thread: den I/O-Thread. Dieser Thread lädt das empfangene Binlog-Protokoll in das Relay-Log-Verzögerungsprotokoll. (5) Ein weiterer Thread im Slave: Der SQL-Thread liest die Informationen im Relay-Protokoll und aktualisiert sie für den Slave. Einzelheiten finden Sie in der folgenden Abbildung.

Gemäß der CAP-Theorie (die hier nicht klar ist) kann diese Architektur offensichtlich keine Echtzeit-Datenkonsistenz garantieren, wie zum Beispiel:
1. Nach dem Schreiben auf den Host legt der Host sofort auf und führt den Master-Slave-Wechsel durch. Dabei können Daten verloren gehen.
2. Wenn auf dem Master ein Schreibvorgang stattfindet, kommt es zu einer Verzögerung bei der Synchronisierung der Daten mit dem Binärprotokoll des Slaves. Wenn Sie den Slave daher sofort abfragen, können Sie die Daten möglicherweise nicht finden. Die Lösung für diese Situation lautet:
1. Aktivieren Sie die halbsynchrone Replikation. Bisher waren die Master-Slave-Synchronisierungsinformationen asynchron, was die Logik der Masterdatenbank nicht beeinflusste. Bei der halbsynchronen Replikation wartet der Host, bis das Binärprotokoll in das Relay-Protokoll (mindestens eines) Slaves geschrieben wurde, bevor der Host entscheidet, es an den Client zurückzugeben.
2. Erzwingen Sie, dass vertrauliche Daten den Host aufrufen. Dies macht jedoch das Konzept der Lese- und Schreibtrennung vage und wird nicht empfohlen
3. Verwenden Sie Middleware (Kanal). Das allgemeine Prinzip besteht darin, dass beim Auftreten einer Schreibanforderung diese im Cache aufgezeichnet wird und die Zeit für die Synchronisierung mit dem Slave geschätzt wird.
Beim Schreiben von Daten in die Masterdatenbank und beim Abfragen der Slavedatenbank wird die geschätzte Zeit zum Schreiben in den Cache verwendet, um die Zeit auf dem Slavecomputer zu bestimmen und zu entscheiden, ob auf die Slavedatenbank gewartet oder die Slavedatenbank direkt abgefragt werden soll.

Dies ist das Ende dieses Artikels zum Verständnis des MySQL-Master-Slave-Synchronisierungsprinzips. Weitere Informationen zum MySQL-Master-Slave-Synchronisierungsprinzip 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!