MySQL Master-Slave-Prinzip und Konfigurationsdetails

MySQL Master-Slave-Konfiguration und Prinzip, zu Ihrer Information, der spezifische Inhalt ist wie folgt

1. Umgebungsauswahl:

1. Centos 6.5

2.MySQL 5.7

2. Was ist MySQL Master-Slave-Replikation?

Die MySQL-Master-Slave-Replikation ist eine seiner wichtigsten Funktionen. Master-Slave-Replikation bedeutet, dass ein Server als Master-Datenbankserver fungiert und ein oder mehrere andere Server als Slave-Datenbankserver. Die Daten auf dem Master-Server werden automatisch auf die Slave-Server kopiert. Bei der mehrstufigen Replikation kann ein Datenbankserver entweder als Master oder als Slave fungieren. Die Grundlage der MySQL-Master-Slave-Replikation besteht darin, dass der Master-Server Binärprotokolle für Datenbankänderungen aufzeichnet und der Slave-Server automatisch Aktualisierungen über die Binärprotokolle des Master-Servers durchführt.

3. Arten der MySQL Master-Slave-Replikation

1. Anweisungsbasierte Replikation

Die auf dem Master-Server ausgeführten Anweisungen werden erneut auf dem Slave-Server ausgeführt. Dies wird in MySQL Version 3.23 und höher unterstützt.

Nachteile: Die Zeit ist möglicherweise nicht vollständig synchronisiert, was zu Abweichungen führt, und der Benutzer, der die Anweisung ausführt, kann ein anderer sein.

2. Zeilenbasierte Replikation

Kopiert den geänderten Inhalt auf dem Hauptserver direkt dorthin, unabhängig davon, welche Anweisung die Änderung verursacht hat. Diese Methode wurde in MySQL 5.0 und höher eingeführt.

Nachteile: Wenn beispielsweise eine Gehaltstabelle 10.000 Benutzer enthält und wir zum Gehalt jedes Benutzers 1.000 hinzufügen, müssen bei der zeilenbasierten Replikation 10.000 Zeilen kopiert werden, was einen großen Mehraufwand verursacht, während bei der anweisungsbasierten Replikation nur eine Anweisung erforderlich ist.

3. Gemischte Replikationsarten

MySQL verwendet standardmäßig die anweisungsbasierte Replikation. Wenn die anweisungsbasierte Replikation Probleme verursacht, wird die zeilenbasierte Replikation verwendet, die MySQL automatisch auswählt.

In der MySQL Master-Slave-Replikationsarchitektur können Lesevorgänge auf allen Servern ausgeführt werden, während Schreibvorgänge nur auf dem Masterserver ausgeführt werden können. Obwohl die Master-Slave-Replikationsarchitektur eine Erweiterung für Lesevorgänge bietet, wird der Masterserver bei vielen Schreibvorgängen (mehrere Slave-Server müssen Daten vom Masterserver synchronisieren) zwangsläufig zu einem Leistungsengpass bei der Replikation im Single-Master-Modell.

4. Grundsatz

1. Master-Slave

Jede Änderung auf dem Master-Server wird im Binärprotokoll gespeichert. Auf dem Slave-Server wird ein E/A-Thread (tatsächlich ein Client-Prozess des Master-Servers) gestartet, der eine Verbindung zum Master-Server herstellt, um das Lesen des Binärprotokolls anzufordern, und das gelesene Binärprotokoll dann in ein lokales Realy-Protokoll schreibt. Starten Sie einen SQL-Thread auf dem Server, um das Realy-Protokoll regelmäßig zu überprüfen. Wenn Änderungen gefunden werden, führen Sie die Änderungen sofort auf dem lokalen Computer aus.

2. Meister-Sklave-Sklave

Wenn es einen Master und mehrere Slaves gibt, ist die Master-Datenbank sowohl für das Schreiben als auch für die Bereitstellung von Binärprotokollen für mehrere Slave-Datenbanken verantwortlich. Zu diesem Zeitpunkt können Sie einige Anpassungen vornehmen und das Binärprotokoll nur einem bestimmten Slave zuweisen. Dieser Slave aktiviert dann das Binärprotokoll und sendet sein eigenes Binärprotokoll an andere Slaves. Oder lassen Sie diesen Slave einfach nichts aufzeichnen und leiten Sie das Binärprotokoll nur an andere Slaves weiter. Diese Architektur bietet möglicherweise eine viel bessere Leistung und die Verzögerung zwischen den Daten sollte auch etwas besser sein.

【Beachten】

1. In der alten Version von MySQL wurde das Slave-Segment der Master-Slave-Replikation nicht von zwei Prozessen, sondern von einem Prozess abgeschlossen, was dann viele Risiken und Leistungsprobleme verursachte. Im Einzelnen geht es um die folgenden Punkte:

1. Ein Prozess macht das Kopieren und Analysieren von Binärprotokollen sowie das Ausführen dieser Protokolle zu einem seriellen Prozess, was die Leistung bis zu einem gewissen Grad einschränkt und die Verzögerung der asynchronen Replikation länger macht.

2. Nachdem die Slave-Seite das Binärprotokoll von der Master-Seite erhalten hat, muss sie den Protokollinhalt analysieren und dann selbst ausführen. Während dieses Vorgangs sind möglicherweise zahlreiche Änderungen auf der Masterseite aufgetreten und zahlreiche neue Protokolle hinzugefügt worden. Wenn während dieser Phase ein nicht behebbarer Fehler im Speicher auf der Masterseite auftritt, sind alle während dieser Phase vorgenommenen Änderungen irreversibel. Wenn der Druck auf der Slave-Seite relativ hoch ist, kann dieser Vorgang länger dauern.

5. Der Prozess der MySQL Master-Slave-Replikation

1. Zwei Situationen: synchrone Replikation und asynchrone Replikation. Die asynchrone Replikation wird hauptsächlich in Produktionsumgebungen verwendet.

2. Der grundlegende Prozess der Replikation:

1. Der I/O-Prozess auf dem Slave verbindet sich mit dem Master und fordert den Log-Inhalt nach der angegebenen Position der angegebenen Datei (oder vom Anfang des Logs) an.

2. Nachdem der Master die Anforderung vom IO-Prozess des Slaves erhalten hat, liest der für die Replikation verantwortliche IO-Prozess die Protokollinformationen nach der angegebenen Position des Protokolls gemäß den Anforderungsinformationen und gibt sie an den IO-Prozess des Slaves zurück. Die zurückgegebenen Informationen umfassen neben den im Protokoll enthaltenen Informationen auch den Namen der Binärprotokolldatei auf der Masterseite, in der die diesmal zurückgegebenen Informationen eingetroffen sind, sowie den Speicherort des Binärprotokolls.

3. Nach dem Empfang der Informationen fügt der IO-Prozess des Slaves den empfangenen Protokollinhalt der Reihe nach an das Ende der Relay-Protokolldatei des Slaves an und zeichnet den Dateinamen und die Position des vom Master gelesenen Binärprotokolls in der Master-Infodatei auf, sodass er dem Master beim nächsten Lesen klar mitteilen kann: „Ich brauche den Protokollinhalt von einer bestimmten Position in einem Binärprotokoll, bitte senden Sie ihn mir.“

4. Nachdem der SQL-Prozess des Slaves den neuen Inhalt erkannt hat, der dem Relay-Protokoll hinzugefügt wurde, analysiert er den Inhalt des Relay-Protokolls sofort in den ausführbaren Inhalt, wenn dieser tatsächlich auf der Master-Seite ausgeführt wird, und führt ihn auf sich selbst aus.

6. Konfiguration:

1. Klären Sie zunächst zwei Sachverhalte:

1. Zwei unabhängige Server oder virtuelle Maschinen.

2. Zwei mit der Vorlage erstellte virtuelle Maschinen.

2. Benennen Sie die beiden Server wie folgt: MySQL-Masterserver und MySQL-Slaveserver.

3. Der Master- und der Slave-Server führen jeweils die folgenden Vorgänge aus:

1. Die MySQL-Version ist konsistent

2. Initialisieren Sie die Tabelle

4. Ändern Sie den MySQL-Masterserver und den MySQL-Slaveserver:

vim /etc/meine.cnf 
[mysqld] 
log-bin=beliebiger Name // Binäres Protokoll aktivieren server-id=beliebige Zahl // Eindeutige ID des Servers, der Standardwert ist 1, normalerweise auf die letzte Ziffer der IP-Adresse eingestellt

5. Im ersten Fall starten Sie die beiden Server direkt neu; im zweiten Fall benennen Sie die auto.cnf-Dateien der beiden Server in auto.cnf.bak um und starten dann den MySQL-Dienst neu.

6. Erstellen Sie ein Konto auf dem MySQL-Masterserver und autorisieren Sie den Slave

Gewähren Sie dem „Benutzernamen“@„%“, identifiziert durch „beliebiges Passwort“, Replikations-Slave auf *.*;

7. Fragen Sie den Status des MySQL-Masterservers ab

Masterstatus anzeigen;

8. Konfigurieren Sie den MySQL-Slave-Server

ändere Master in 
master_host = 'IP-Adresse des MySQL-Masterservers', 
master_user = 'der zuvor auf dem MySQL-Masterserver erstellte Benutzername', 
master_password = 'zuvor erstelltes Passwort', 
master_log_file = 'Name der binären Statusdatei des MySQL-Masterservers', 
master_log_pos='Positionswert im MySQL-Masterserverstatus';

9. Slave aktivieren

Slave starten;

10. Überprüfen Sie den Status des MySQL-Slave-Servers

Slave-Status anzeigen\G

Überprüfen

Slave_IO_Running: Ja //Dieser Status muss JA sein

Slave_SQL_Running: Ja //Dieser Status muss JA sein

Wenn alle Änderungen JA lauten, ist die Master-Slave-Konfiguration erfolgreich. Wenn der MySQL-Masterserver aktualisiert wird, wird der Slaveserver entsprechend der spezifischen Konfiguration synchronisiert.

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.