Nachdem es zu einer MySQL-Master-Slave-Verzögerung kam, begann ich darüber nachzudenken, was Master-Slave-Replikation ist. Wie wird es erreicht? Wie funktioniert es? Also fing ich an, Informationen und Artikel nachzuschlagen, und nun fasse ich hier zusammen, was ich verstanden habe, um meinen Eindruck zu vertiefen.
Warum müssen wir eine Master-Slave-Replikation durchführen?
1. In einem System mit komplexem Geschäft gibt es ein Szenario, in dem eine SQL-Anweisung die Tabelle sperren muss, was dazu führt, dass der Lesedienst vorübergehend nicht verwendet werden kann, was sich stark auf den laufenden Geschäftsbetrieb auswirkt -Slave-Replikation. Lassen Sie die Hauptbibliothek für das Schreiben und die Slave-Bibliothek für das Lesen verantwortlich sein. Auf diese Weise kann der normale Betrieb des Unternehmens durch Lesen aus der Slave-Bibliothek sichergestellt werden.
2. Hot-Backup von Daten
3. 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.
Was ist das Prinzip der MySQL-Master-Slave-Replikation?
binlog: Binärprotokoll, eine Binärdatei, die alle Update-Ereignisprotokolle in der Hauptbibliothek speichert.
Die Grundlage der Master-Slave-Replikation besteht darin, dass die Master-Datenbank alle Änderungen in der Datenbank im Binlog aufzeichnet. Binlog ist eine Datei, die alle Änderungen an der Datenbankstruktur oder dem Inhalt ab dem Start des Datenbankservers speichert.
MySQL-Master-Slave-Replikation ist ein asynchroner Replikationsprozess. Die Master-Bibliothek sendet Aktualisierungsereignisse an die Slave-Bibliothek, die Slave-Bibliothek liest die Aktualisierungsdatensätze und führt die Aktualisierungsdatensätze aus, um den Inhalt der Slave-Bibliothek konsistent zu machen mit der Hauptbibliothek.
Solange in der Hauptdatenbank ein Aktualisierungsereignis auftritt, wird es nacheinander in das Binlog geschrieben und dann zur Replikation aus der Slave-Datenbank an die Slave-Datenbank als Datenquelle ü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 der Kopiervorgang beginnt, erstellt die Slave-Bibliothek zwei Threads zur Verarbeitung:
E/A-Thread der Slave-Bibliothek. Wenn die Ausführung der START SLAVE-Anweisung von der Slave-Bibliothek aus beginnt, erstellt die Slave-Bibliothek einen E/A-Thread, der eine Verbindung zur Hauptbibliothek herstellt und die Hauptbibliothek auffordert, die Aktualisierungsdatensätze im Binlog an die Slave-Bibliothek zu senden.
Der I/O-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 Datenbank. Erstellen Sie einen SQL-Thread aus der Bibliothek. Dieser Thread liest die vom E/A-Thread der Bibliothek in das Relay-Protokoll geschriebenen Aktualisierungsereignisse und führt sie aus.
Sie können wissen, dass es für jede Master-Slave-Replikationsverbindung drei Threads gibt. 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 von zwei unabhängigen 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 sie beim Starten hier zwar langsam ausgeführt werden, ihr E/A-Thread kann jedoch schnell alle Binlog-Inhalte aus der Hauptbibliothek lesen, obwohl ihr SQL-Thread langsam ist. Selbst wenn die Slave-Bibliothek aufhört zu laufen, bevor der SQL-Thread die Ausführung aller Leseanweisungen abgeschlossen hat, hat der E/A-Thread auf diese Weise zumindest alle Inhalte vollständig gelesen und sie sicher im lokalen Relay-Protokoll der Slave-Bibliothek gesichert. , bereit zur Ausführung von Anweisungen beim nächsten Start der Slave-Bibliothek.
Überprüfen Sie den Status der Master-Slave-Replikation
Wenn die Master-Slave-Replikation läuft und Sie den Betriebsstatus der beiden Threads in der Slave-Bibliothek überprüfen möchten, können Sie Folgendes ausführen: show Slave StatusG“ in der Slave-Bibliotheksanweisung können die folgenden Felder Ihnen die gewünschten Informationen liefern:
Master_Log_File — 上一个从主库拷贝过来的binlog文件
Read_Master_Log_Pos — 主库的binlog文件被拷贝到从库的relay log中的位置
Relay_Master_Log_File — SQL线程当前处理中的relay log文件
Exec_Master_Log_Pos — 当前binlog文件正在被执行的语句的位置
Nach dem Login kopieren
Der gesamte Master-Slave-Replikationsprozess kann anhand des folgenden Diagramms verstanden werden:
Schritt 1: Die Aktualisierungsereignisse (Update, Einfügen, Löschen) der Hauptdatenbank-Datenbank werden in das Binlog geschrieben
Schritt 2: Initiieren Sie eine Verbindung von der Datenbank und stellen Sie eine Verbindung zur Hauptbibliothek her
Schritt 3: Zu diesem Zeitpunkt erstellt die Hauptbibliothek einen Binlog-Dump-Thread und sendet das Binlog Inhalt in die Slave-Bibliothek
Schritt 4: Erstellen Sie nach dem Start in der Bibliothek einen I/O-Thread, lesen Sie den Binlog-Inhalt aus der Hauptbibliothek und schreiben Sie ihn in das Relay-Protokoll
Schritt 5: Außerdem wird ein SQL-Thread erstellt. 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 den Slave db
注：上面的解释是解释每一步做了什么，整个mysql主从复制是异步的，不是按照上面的步骤执行的。
Nach dem Login kopieren
Das obige ist der detaillierte Inhalt vonWarum wird eine Master-Slave-Replikation durchgeführt?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!
