Was ist MySQL-Master-Slave-Replikation?

In MySQL bedeutet Master-Slave-Replikation, dass Daten von einem MySQL-Datenbankserver-Masterknoten auf einen oder mehrere Slave-Knoten kopiert werden können. Standardmäßig wird die asynchrone Replikation verwendet. Die Vorteile der Verwendung der Master-Slave-Replikation: 1. Lassen Sie die Master-Datenbank für das Schreiben und die Slave-Datenbank für das Lesen verantwortlich sein. Wenn die Master-Datenbank die Tabelle sperrt, kann der normale Betrieb des Unternehmens durch Lesen vom Slave sichergestellt werden 2. Hot-Backup von Daten ist möglich. 3. Durch die Erweiterung der Architektur kann die Häufigkeit des Festplatten-E/A-Zugriffs verringert und die E/A-Leistung einer einzelnen Maschine verbessert werden.

Die Betriebsumgebung dieses Tutorials: Windows7-System, MySQL8-Version, Dell G3-Computer.

Was ist MySQL-Master-Slave-Replikation?

MySQL-Master-Slave-Replikation bedeutet, dass Daten von einem MySQL-Datenbankserver-Masterknoten auf einen oder mehrere Slave-Knoten kopiert werden können. MySQL verwendet standardmäßig die asynchrone Replikation, sodass der Slave-Knoten nicht ständig auf den Master-Server zugreifen muss, um seine eigenen Daten zu aktualisieren. Datenaktualisierungen können über eine Remote-Verbindung durchgeführt werden. Der Slave-Knoten kann alle Datenbanken oder bestimmte Datenbanken kopieren die Masterdatenbank oder bestimmte Tabellen.

Warum brauchen wir eine Master-Slave-Replikation?

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 das laufende Geschäft auswirkt Durch die Replikation ist die Master-Bibliothek für das Schreiben und die Slave-Bibliothek für das Lesen verantwortlich. Auf diese Weise kann der normale Betrieb des Unternehmens durch Lesen aus der Slave-Bibliothek sichergestellt werden, auch wenn die Hauptbibliothek die Tabelle sperrt.

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.

MySQL-Replikationsprinzip

Prinzip:

(1) Der Master-Server zeichnet die Datenänderungen im Binärprotokoll auf. Wenn sich die Daten auf dem Master ändern, werden die Änderungen in das Binärprotokoll geschrieben.

(2) Der Slave-Server erkennt, ob sich das Master-Binärprotokoll innerhalb eines bestimmten Zeitintervalls geändert hat. Wenn es sich ändert, startet er einen I/OThread, um das Master-Binärereignis anzufordern

(3) Gleichzeitig Der Master-Knoten startet einen Dump-Thread, um binäre Ereignisse an ihn zu senden und im lokalen Relay-Protokoll des Slave-Knotens zu speichern. Der Slave-Knoten startet den SQL-Thread, um das Binärprotokoll aus dem Relay-Protokoll zu lesen und wiederzugeben Es wird lokal hergestellt, um sicherzustellen, dass die Daten mit denen des Hauptknotens übereinstimmen. Schließlich wechseln I/OThread und SQLThread in den Ruhezustand und warten auf das nächste Mal, wenn sie aufgeweckt werden.

Das heißt:

• Die Slave-Bibliothek generiert zwei Threads, einen E/A-Thread und einen SQL-Thread.
• Der E/A-Thread fordert das Binlog der Hauptbibliothek an und schreibt das erhaltene Binlog in der lokalen Relay-Log-Datei (Relay-Log); und nacheinander in SQL-Anweisungen zur Ausführung geparst;
• Hinweis:

– Der Master zeichnet die Operationsanweisungen im Binlog-Protokoll auf und erteilt dann dem Slave die Remote-Verbindungsberechtigung (der Master muss die Binlog-Binärdatei aktivieren). Log-Funktion; normalerweise aus Gründen der Datensicherheit aktiviert der Slave auch die Binlog-Funktion.

• –Slave öffnet zwei Threads: IO-Thread und SQL-Thread. Darunter: Der E/A-Thread ist dafür verantwortlich, den Binlog-Inhalt des Masters in das Relay-Protokoll zu lesen; der SQL-Thread ist dafür verantwortlich, den Binlog-Inhalt aus dem Relay-Protokoll zu lesen und ihn in der Slave-Datenbank zu aktualisieren, um sicherzustellen, dass der Slave Daten und Stammdaten werden konsistent gepflegt.

• –Für die MySQL-Replikation sind mindestens zwei MySQL-Dienste erforderlich. Natürlich können MySQL-Dienste auf verschiedenen Servern verteilt sein, oder es können mehrere Dienste auf einem Server gestartet werden.

• –Die MySQL-Replikation ist am besten geeignet, um sicherzustellen, dass die MySQL-Versionen auf dem Master- und dem Slave-Server gleich sind (wenn die Versionen nicht konsistent sein können, stellen Sie sicher, dass die Version des Master-Knotens niedriger ist als die Version des Slave-Knotens )

• –Master und Slave Die Zeit zwischen den beiden Knoten muss synchronisiert werden Anweisung und stellt alle Bedingungen für den verbundenen Benutzer bereit (Benutzer, Passwort, Port, IP) und teilt der Slave-Bibliothek die Startposition des Binärprotokolls (Dateiname, Positionsnummer) mit. Stellen Sie eine Verbindung her zwischen dem IO-Thread der Slave-Bibliothek und dem Dump-Thread der Hauptbibliothek.

3. Basierend auf dem Dateinamen und der Positionsnummer, die von der Anweisung „Change Master to“ aus der Slave-Bibliothek bereitgestellt werden, initiiert der E/A-Thread eine Binlog-Anfrage an die Master-Bibliothek.

• 4. Der Dump-Thread der Hauptbibliothek sendet das lokale Binlog in Form von Ereignissen gemäß der Anforderung der Slave-Bibliothek an den E/A-Thread der Slave-Bibliothek.

5. Binlog-Ereignisse vom Bibliotheks-IO-Thread empfangen und im lokalen Relay-Log speichern. Die übertragenen Informationen werden in master.info aufgezeichnet

6. Wenden Sie Relay-Log aus dem SQL-Thread der Datenbank an und zeichnen Sie die angewendeten Informationen in Relay-Log.info auf. Standardmäßig wird das angewendete Relay automatisch gelöscht

(1) Ein Master und ein Slave. (2) Master-Master-Kopie. (3) Ein Master und mehrere Slaves. (4) Mehrere Master und eins Von

(5) Kaskadenreplikation



MySQL-Master-Slave-Synchronisationsverzögerungsanalyse

MySQLs Master-Slave-Replikation ist ein Single-Threaded-Vorgang , und die Hauptbibliothek führt alle von und DML generierten Protokolle in das Binlog aus. Da das Binlog sequentiell geschrieben wird, ist es sehr effizient, dass der SQL-Thread-Thread die DDL- und DML-Operationsereignisse der Hauptbibliothek im Slave wiedergibt. Die E/A-Operationen von DML und DDL sind zufällig und nicht sequentiell, daher sind die Kosten viel höher. Da der SQL-Thread andererseits auch Single-Threaded ist, ist die Anzahl der generierten DMLs höher, wenn die Parallelität der Hauptbibliothek hoch ist Die Verarbeitungsgeschwindigkeit überschreitet die Kapazität des SQL-Threads des Slaves oder es kommt zu einer Verzögerung, wenn im Slave eine große Abfrageanweisung vorhanden ist, die eine Sperrwartezeit verursacht.

Lösung: 1. Die Implementierung der Geschäftspersistenzschicht übernimmt eine Subdatenbankarchitektur, und der MySQL-Dienst kann parallel erweitert werden, um den Druck zu verteilen.

2. Getrenntes Lesen und Schreiben in einer einzigen Bibliothek, einem Master und mehreren Slaves, Master-Schreibvorgängen und Slave-Lesevorgängen, um den Druck zu verteilen. Auf diese Weise ist der Druck der Slave-Bibliothek höher als der der Hauptbibliothek, wodurch die Hauptbibliothek geschützt wird.

3. Die Service-Infrastruktur fügt eine Memcache- oder Redis-Cache-Schicht zwischen dem Unternehmen und MySQL hinzu. Reduzieren Sie den Lesedruck von MySQL.

4. MySQL wird für verschiedene Unternehmen physisch auf verschiedenen Maschinen platziert, um den Druck zu verteilen.

5. Verwenden Sie ein besseres Hardwaregerät als die Hauptbibliothek, da der Slave-MySQL weniger Druck hat und die Verzögerung natürlich kleiner wird.

6. Verwenden Sie leistungsstärkere Hardware-Geräte

[Verwandte Empfehlungen: MySQL-Video-Tutorial]

Das obige ist der detaillierte Inhalt vonWas ist MySQL-Master-Slave-Replikation?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!