MySQL-Master-Slave-Replikationsprinzip: Zuerst sendet die Master-Bibliothek ein Aktualisierungsereignis an die Slave-Bibliothek, dann liest die Slave-Bibliothek den Aktualisierungsdatensatz und führt schließlich den Aktualisierungsdatensatz aus Bibliothek.
Verwandte kostenlose Lernempfehlungen: MySQL-Video-Tutorial
MySQL-Master-Slave-Replikationsprinzip:
Warum Master-Slave-Replikation
In komplexen Unternehmen Systeme In diesem Szenario gibt es eine Situation, in der eine SQL-Anweisung eine Tabellensperre erfordert, was dazu führt, dass der Lesedienst vorübergehend nicht verwendet werden kann, was sich stark auf das laufende Unternehmen auswirkt. Verwenden Sie die Master-Slave-Replikation, um die Master-Datenbank für das Schreiben verantwortlich zu machen und die Slave-Datenbank ist für das Lesen verantwortlich. Selbst wenn die Master-Datenbank die Tabelle sperrt, kann der normale Betrieb des Unternehmens durch Lesen aus der Slave-Datenbank gewährleistet werden.
Führen Sie eine Hot-Sicherung der Daten durch. Nachdem die Hauptdatenbank ausgefallen ist, kann die Hauptdatenbank rechtzeitig ersetzt werden, um die Geschäftsverfügbarkeit sicherzustellen.
Erweiterung der Architektur. Das Geschäftsvolumen wird immer größer und die Häufigkeit des E/A-Zugriffs ist zu hoch, was von einer einzelnen Maschine nicht erfüllt werden kann. Derzeit wird Multi-Datenbank-Speicher verwendet, um die Häufigkeit des Festplatten-E/A-Zugriffs zu reduzieren und die I/O-Leistung einer einzelnen Maschine verbessern.
MySQL-Master-Slave-Replikationsprozess
Die Aktualisierungsereignisse (Aktualisieren, Einfügen, Löschen) der Hauptdatenbank-Datenbank werden in das Binlog geschrieben.
Die Hauptdatenbank erstellt einen Binlog-Dump-Thread und sendet den Binlog-Inhalt aus der Bibliothek
Beginnen Sie von der Bibliothek und initiieren Sie eine Verbindung, stellen Sie eine Verbindung zur Hauptbibliothek her
Erstellen Sie nach dem Start von der Slave-Bibliothek einen E/A-Thread, lesen Sie den Binlog-Inhalt aus der Hauptbibliothek und schreiben Sie ihn hinein das Relay-Protokoll
Erstellen Sie nach dem Start in der Slave-Bibliothek einen SQL-Thread, lesen Sie den Inhalt aus dem Relay-Protokoll, führen Sie das Leseaktualisierungsereignis ab der Position Exec_Master_Log_Pos aus und schreiben Sie den aktualisierten Inhalt in die Datenbank des Slaves
Hinweis: Die Der obige Prozess ist ein relativer Prozess, kein absoluter Prozess. Das Prinzip der MySQL-Master-Slave-Replikation ist ein asynchroner Replikationsprozess. Die Master-Bibliothek sendet Aktualisierungsereignisse an die Slave-Bibliothek Liest den Aktualisierungsdatensatz und führt den Aktualisierungsdatensatz aus, sodass der Inhalt der Slave-Bibliothek mit dem der Master-Bibliothek konsistent ist.
binlog: Binärprotokoll, eine Binärdatei, die alle Update-Ereignisprotokolle in der Hauptbibliothek speichert. Binlog ist eine Datei, die alle Änderungsdatensätze (Datenbankstruktur und -inhalt) der Datenbank ab dem Start des Datenbankdienstes speichert. Solange in der Hauptbibliothek ein Aktualisierungsereignis auftritt, wird es nacheinander in das Binlog geschrieben und dann an die Slave-Bibliothek als Datenquelle für die Replikation von der Slave-Bibliothek übertragen. Binlog-Ausgabethread: Immer wenn eine Slave-Bibliothek eine Verbindung zur Hauptbibliothek herstellt, erstellt die Hauptbibliothek einen Thread und sendet den Binlog-Inhalt an die Slave-Bibliothek. Für jedes SQL-Ereignis, das an die Slave-Bibliothek gesendet werden soll, wird es vom Binlog-Ausgabethread gesperrt. Sobald das Ereignis vom Thread gelesen wurde, wird die Sperre aufgehoben. Auch wenn das Ereignis vollständig an die Slave-Bibliothek gesendet wurde, wird die Sperre aufgehoben.
Wenn in der Slave-Bibliothek die Replikation beginnt, erstellt die Slave-Bibliothek den E/A-Thread der Slave-Bibliothek und den SQL-Thread der Slave-Bibliothek für die Kopierverarbeitung.
E/A-Thread der Slave-Bibliothek: Wenn die Ausführung der START SLAVE-Anweisung in der Slave-Bibliothek beginnt, erstellt die Slave-Bibliothek einen E/A-Thread, der eine Verbindung zur Hauptbibliothek herstellt und die Hauptbibliothek auffordert, die Aktualisierungsdatensätze im Binlog zu senden zur Slave-Bibliothek. Der E/A-Thread der Slave-Bibliothek liest die vom Binlog-Ausgabethread der Hauptbibliothek gesendeten Aktualisierungen und kopiert diese Aktualisierungen in lokale Dateien, einschließlich Relay-Protokolldateien.
SQL-Thread aus der Bibliothek: Erstellen Sie einen SQL-Thread aus der Bibliothek. Dieser Thread liest die vom I/O-Thread der Bibliothek in das Relay-Protokoll geschriebenen Update-Ereignisse und führt sie aus.
Zusammenfassend lässt sich Folgendes erkennen:
Für jede Master-Slave-Replikationsverbindung gibt es drei Threads. Eine Hauptbibliothek mit mehreren Slave-Bibliotheken erstellt einen Binlog-Ausgabethread für jede mit der Hauptbibliothek verbundene Slave-Bibliothek. Jede Slave-Bibliothek verfügt über einen eigenen E/A-Thread und SQL-Thread.
Durch die Erstellung zweier unabhängiger Threads trennt die Slave-Bibliothek beim Kopieren das Lesen und Schreiben der Slave-Bibliothek. Selbst wenn der Thread, der für die Ausführung verantwortlich ist, langsamer läuft, wird der Thread, der für das Lesen der Update-Anweisung verantwortlich ist, nicht langsamer. Wenn die Slave-Bibliothek beispielsweise eine Weile nicht ausgeführt wurde, kann ihr E/A-Thread beim Starten hier schnell alle Binlog-Inhalte aus der Hauptbibliothek lesen, obwohl ihr SQL-Thread langsam ausgeführt wird. Selbst wenn die Slave-Bibliothek aufhört zu laufen, bevor der SQL-Thread alle Leseanweisungen ausgeführt hat, hat der E/A-Thread auf diese Weise zumindest alle Inhalte vollständig gelesen und sicher im lokalen Relay-Protokoll der Slave-Bibliothek gesichert. , bereit zur Ausführung von Anweisungen beim nächsten Start der Slave-Bibliothek.
Das obige ist der detaillierte Inhalt vonWas ist das Prinzip der MySQL-Master-Slave-Replikation?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!