Detaillierte Erläuterung der Rolle und des Funktionsprinzips der MySQL-Master-Slave-Replikation

1. Was ist Master-Slave-Replikation?

Mithilfe der Master-Slave-Replikation wird eine Datenbankumgebung eingerichtet, die genau mit der Masterdatenbank identisch ist und als Slave-Datenbank bezeichnet wird. Bei der Masterdatenbank handelt es sich im Allgemeinen um eine quasi-Echtzeit-Geschäftsdatenbank. In der am häufigsten verwendeten MySQL-Datenbank wird die asynchrone Zuweisung einzelner Elemente unterstützt. Während des Migrationsprozesses fungiert ein Server als Masterserver und der andere Server als Slaveserver. Der Masterserver schreibt die Aktualisierungsinformationen in eine spezielle Binärdatei.

Zur Verfolgung der Protokollzyklen wird ein Dateiindex geführt. Dieses Protokoll kann Aktualisierungen aufzeichnen und an den Slave-Server senden. Wenn ein Slave-Server eine Verbindung zum Master-Server herstellt, benachrichtigt der Slave-Server den Master-Server, um den Speicherort der letzten erfolgreichen Aktualisierung in der Protokolldatei des Slave-Servers zu lesen. Der Slave empfängt dann ab diesem Zeitpunkt alle Updates, sperrt sich und wartet, bis er vom Master über neue Updates benachrichtigt wird.

2. Die Rolle der Master-Slave-Replikation

Erstens, um die Datensicherheit zu gewährleisten. Führen Sie ein Hot-Backup der Daten als Backup-Datenbank durch. Wenn der Hauptdatenbankserver ausfällt, können Sie zur Slave-Datenbank wechseln, um weiterzuarbeiten und Datenverlust zu vermeiden.

Die zweite Möglichkeit besteht darin, die E/A-Leistung zu verbessern. Mit zunehmendem Geschäftsvolumen in der täglichen Produktion steigt auch die Häufigkeit des E/A-Zugriffs, was von einer einzelnen Maschine nicht bewältigt werden kann. Zu diesem Zeitpunkt kann die Speicherung mehrerer Bibliotheken die Häufigkeit des Festplatten-E/A-Zugriffs effektiv reduzieren und die E/A-Leistung eines einzelnen Geräts verbessern.

Der dritte Aspekt ist die Trennung von Lesen und Schreiben, die es der Datenbank ermöglicht, eine größere Parallelität zu unterstützen. Dies ist insbesondere bei der Berichterstellung wichtig. Da einige Berichts-SQL-Anweisungen sehr langsam sind, wird die Tabelle gesperrt, was sich auf den Front-End-Dienst auswirkt. Wenn die Rezeption den Master und der Bericht den Slave verwendet, führt das Berichts-SQL nicht dazu, dass die Rezeption gesperrt wird, wodurch die Geschwindigkeit der Rezeption sichergestellt wird.

3. Das Prinzip der Master-Slave-Replikation

An der Master-Slave-Replikation beteiligte Dateien

Hauptbibliothek: binlog

Aus der Bibliothek:

• Relaisprotokoll Relaisprotokoll
• master.info Master-Datenbankinformationsdatei
• relaylog.info Relaylog-Anwendungsinformationen

Drei Threads an der Master-Slave-Replikation beteiligt

Hauptbibliothek:

Binlog_Dump-Thread:

Aus der Bibliothek:

SLAVE_IO_THREAD

SLAVE_SQL_THREAD

Das konkrete Prinzip ist in der Abbildung dargestellt:

1. Führen Sie den Befehl „Change Master to“ aus der Datenbank aus (die Verbindungsinformationen der Masterdatenbank + der Startpunkt der Replikation).
2. Die oben genannten Informationen werden in der Datei master.info aus der Datenbank aufgezeichnet
3. Führen Sie den Befehl „Start Slave“ aus der Datenbank aus, um die beiden Threads SLAVE_IO_THREAD und SLAVE_SQL_THREAD sofort zu starten

4. Lesen Sie aus der Datenbank SLAVE_SQL_THREAD die Informationen in der Datei master.info, um die Informationen zu IP, PORT, Benutzer, Pass und Binlog-Standort zu erhalten

5. Die Slave-Datenbank SLAVE_IO_THREAD fordert eine Verbindung zur Master-Datenbank an. Die Master-Datenbank stellt einen SLAVE_IO_THREAD zur Interaktion mit dem SLAVE_SQL_THREAD bereit.

6.SLAVE_IO_THREAD fordert das neue Binlog der Master-Datenbank basierend auf den Standortinformationen des Binlogs an

7. Die Master-Datenbank verwendet Binlog_DUMP_Thread, um das neueste Binlog über das Netzwerk TP an den SALVE_IO_THREAD der Slave-Datenbank zu senden

8.SLAVE_IO_THREAD empfängt das neue Binlog, speichert es im TCP/IP-Cache, gibt sofort ACK an den Master zurück und aktualisiert master.info

9. SLAVE_IO_THREAD überträgt die Daten aus dem TCP/IP-Cache in das Disk-Relaylog.

10.SLAVE_SQL_THREAD liest die Informationen in relay.info und erhält die Standortinformationen des zuletzt angewendeten Relaylogs

11.SLAVE_SQL_THREAD spielt das neueste Relaylog entsprechend der letzten Position erneut ab und aktualisiert die Relay.info-Informationen erneut

12. Die Datenbank löscht das Anwendungsrelais automatisch zur regelmäßigen Bereinigung

Sobald die Master-Slave-Replikation erfolgreich eingerichtet ist, werden alle neuen Änderungen in der Masterdatenbank über den slave_dump_THREAD an den SLAVE_IO_THREAD gesendet, was die Echtzeitnatur der Master-Slave-Replikation verbessert.

Das Obige ist der vollständige Inhalt dieses Artikels. Ich hoffe, er wird für jedermanns Studium hilfreich sein. Ich hoffe auch, dass jeder 123WORDPRESS.COM unterstützen wird.