Wie erreicht MySQL eine Master-Slave-Synchronisierung?

Die Master-Slave-Synchronisierung, auch Master-Slave-Replikation genannt, ist eine von MySQL bereitgestellte Hochverfügbarkeitslösung, die die Master-Slave-Datenkonsistenz gewährleistet.

In einer Produktionsumgebung gibt es viele unkontrollierbare Faktoren, wie beispielsweise den Ausfall von Datenbankdiensten. Um eine hohe Verfügbarkeit der Anwendung zu gewährleisten, muss auch die Datenbank hochverfügbar sein.

Daher wird in Produktionsumgebungen die Master-Slave-Synchronisierung verwendet. Bei kleinen Anwendungsbereichen werden im Allgemeinen ein Master und ein Backup verwendet.

Neben der Möglichkeit, bei einem Ausfall des Datenbankdienstes schnell zur Standby-Datenbank zu wechseln und so eine Nichtverfügbarkeit der Anwendung zu vermeiden, bietet die Verwendung der Master-Slave-Synchronisierung die folgenden Vorteile:

Verbessern Sie die Lese-Parallelität der Datenbank. Die meisten Anwendungen erfordern mehr Lese- als Schreibvorgänge. Verwenden Sie eine Master-Slave-Synchronisierungslösung. Wenn der Nutzungsumfang zunimmt, können Sie die Slave-Datenbank erweitern, um die Lesefähigkeit zu verbessern.

Durch Backup und Master-Slave-Synchronisierung kann eine vollständige Echtzeit-Backup-Datenbank erstellt werden.

Schnelle Wiederherstellung: Wenn in der primären Datenbank ein Fehler auftritt (z. B. versehentliches Löschen einer Tabelle), können die Daten schnell über die Standby-Datenbank wiederhergestellt werden. Für umfangreiche Anwendungen mit geringer Toleranz gegenüber der Geschwindigkeit der Datenwiederherstellung kann eine Backup-Datenbank mit einem Daten-Snapshot konfiguriert werden, der eine halbe Stunde nach der Primärdatenbank erstellt wird. Wenn eine Tabelle versehentlich aus der Primärdatenbank gelöscht wird, kann sie mithilfe der Backup-Datenbank und des Binärprotokolls schnell wiederhergestellt werden, wobei die maximale Wartezeit eine halbe Stunde beträgt.

Nachdem wir nun besprochen haben, was Master-Slave-Synchronisierung ist und welche Vorteile sie bietet, wollen wir nun verstehen, wie die Master-Slave-Synchronisierung erreicht wird.

Implementierungsprinzip der Master-Slave-Synchronisation

Lassen Sie uns zunächst das Prinzip der Master-Slave-Synchronisierung verstehen. Im Folgenden wird anhand einer Update-Anweisung erläutert, wie die Master- und Slave-Datenbanken synchronisiert werden.

Die obige Abbildung ist ein vollständiges Flussdiagramm einer Update-Anweisung, die auf Knoten A ausgeführt und dann mit Knoten B synchronisiert wird. Die einzelnen Schritte sind:

1. Die Masterdatenbank empfängt eine vom Client gesendete Aktualisierungsanweisung, führt die interne Transaktionslogik aus und schreibt gleichzeitig das Binärprotokoll.
2. Die Standby-Datenbank verwendet den Befehl „Change Master“, um die IP, den Port, den Benutzernamen und das Passwort der Master-Datenbank sowie die Position festzulegen, von der aus mit der Anforderung des Binärprotokolls begonnen werden soll. Dieser Speicherort enthält den Dateinamen und den Offset.
3. Führen Sie den Befehl „Start Slave“ auf der Slave-Datenbank aus, um zwei Threads zu starten: io_thread und sql_thread. Der io_thread ist für die Verbindung mit dem Host verantwortlich.
4. Nachdem die Master-Datenbank den Benutzernamen und das Passwort überprüft hat, liest sie das Binärprotokoll entsprechend dem empfangenen Speicherort und sendet es an die Slave-Datenbank.
5. Nach dem Empfang des Binlogs schreibt die Standby-Datenbank es in eine lokale Datei (Relay-Log, Transferdatei).
6. Die Standby-Datenbank liest die Übertragungsdatei, analysiert den Befehl und führt ihn dann aus.
   

Das Funktionsprinzip der Master-Slave-Synchronisierung besteht eigentlich aus einer vollständigen Sicherung plus Wiederherstellung der Binärprotokollsicherung. Der Unterschied besteht darin, dass der Wiederherstellungsvorgang dieses Binärprotokolls grundsätzlich in Echtzeit erfolgt.

Die Standby-Datenbank verwendet zwei Threads, um die Synchronisierung durchzuführen:

• Einer ist der I/O-Thread, der dafür verantwortlich ist, das Binärprotokoll der Hauptbibliothek zu lesen und als Relay-Protokoll zu speichern.
• Einer ist der SQL-Thread, der für die Ausführung des Relay-Protokolls verantwortlich ist.

Aus dem obigen Prozess können wir erkennen, dass der Schlüssel zur Master-Slave-Synchronisation binlog ist

Zwei gängige Aktiv/Standby-Umschaltvorgänge

MS-Struktur

In der MS-Struktur gibt es zwei Knoten, von denen einer als primäre Datenbank und der andere als Sicherungsdatenbank dient. Die beiden Knoten dürfen ihre Rollen nicht tauschen.

Im Zustand 1 greifen die Lese- und Schreibvorgänge des Clients direkt auf Knoten A zu, und Knoten B ist die Sicherungsdatenbank von A. Er synchronisiert lediglich alle Aktualisierungen von A und führt sie lokal aus. Dadurch bleiben die Daten auf den Knoten B und A gleich.

Wenn ein Umschalten erforderlich ist, wechseln Sie in den Zustand 2. Zu diesem Zeitpunkt liest und schreibt der Client auf Knoten B und Knoten A ist die Sicherungsdatenbank von B.

Doppel-M-Struktur

Duale M-Struktur, zwei Knoten, einer als primäre Datenbank und einer als Sicherungsdatenbank, wobei die beiden Knoten ihre Rollen tauschen können.

Im Vergleich mit dem vorherigen MS-Strukturdiagramm können wir feststellen, dass der einzige Unterschied zwischen der dualen M-Struktur und der MS-Struktur darin besteht, dass es eine weitere Linie gibt, d. h. die Knoten A und B stehen immer in einer Master-Slave-Beziehung zueinander. Somit ist es nicht notwendig, die Master-Slave-Beziehung beim Umschalten zu verändern.

Das zirkuläre Kopierproblem der Doppel-M-Struktur

Im tatsächlichen Produktionseinsatz wird in den meisten Fällen die Doppel-M-Struktur verwendet. Allerdings gibt es bei der Doppel-M-Struktur noch ein Problem, das gelöst werden muss.

Wenn die Geschäftslogik auf Knoten A aktualisiert wird, wird ein Binärprotokoll generiert und mit Knoten B synchronisiert. Nachdem Knoten B synchronisiert wurde, wird auch ein Binärprotokoll generiert. (log_slave_updates ist auf „on“ gesetzt, was bedeutet, dass die Standby-Datenbank auch Binärprotokolle generiert).

Wenn Knoten A auch die Sicherungsdatenbank von Knoten B ist, wird das Binärprotokoll von Knoten B auch an Knoten A gesendet, was zu einer zirkulären Replikation führt.

Lösung:

1. Legen Sie die Server-ID des Knotens fest. Sie muss unterschiedlich sein. Andernfalls ist es nicht zulässig, sie als Master-Slave-Struktur festzulegen.
2. Wenn die Sicherungsdatenbank das Binärprotokoll empfängt und wiedergibt, wird dieselbe Server-ID wie im Originaldatensatz aufgezeichnet, d. h., sie gehört der Person, die sie generiert hat.
3. Beim Empfang des Binärprotokolls ermittelt jeder Knoten die Server-ID und verwirft sie, wenn es seine eigene ist.

Der Prozess nach der Lösung:

1. Die Geschäftslogik führt Aktualisierungen auf Knoten A aus und generiert ein Binärprotokoll mit der Server-ID von Knoten A.
2. Nachdem Knoten B das von Knoten A gesendete Binärprotokoll empfangen und die Ausführung abgeschlossen hat, wird ein Binärprotokoll mit der Server-ID von Knoten A generiert.
3. Nachdem Knoten A das Binärprotokoll empfangen hat und feststellt, dass es sein eigenes ist, verwirft er es. Die Endlosschleife wird hier unterbrochen.

Oben sind die Details beschrieben, wie MySQL die Master-Slave-Synchronisierung erreicht. Weitere Informationen zur MySQL-Master-Slave-Synchronisierung finden Sie in den anderen verwandten Artikeln auf 123WORDPRESS.COM!