Detaillierte Erläuterung der Konfiguration und Einführung des MySQL-Halbsynchron-Replikationsprinzips

Einführung in die Umgebung:

Ubuntu Server 16.04.2+MySQL 5.7.17 Community-Server (GPL)

MySQL-Installation

Installation über APT, Adresse des offiziellen Anleitungsdokuments:
https://dev.mysql.com/downloads/repo/apt/

1. Laden Sie mysql-apt-config_0.8.3-1_all.deb herunter

2. Installieren Sie deb

Eine Kurzanleitung zur Verwendung des MySQL APT-Repository:
https://dev.mysql.com/doc/mysql-apt-repo-quick-guide/en/

>sudo dpkg -i mysql-apt-config_0.8.3-1_all.deb

3. Quelle aktualisieren

>sudo apt-get update

4. MySQL installieren

>sudo apt-get installiere MySQL-Server

5. Wählen Sie die Installation aus und legen Sie das Kennwort gemäß den Anweisungen fest.

Darüber hinaus müssen Sie es einrichten, die IP binden und Port 3306 der Firewall öffnen. Hier lernen wir hauptsächlich die halbsynchrone MySQL-Replikation und werden nicht viel über die Installation von MySQL erklären. Wenn Sie Fragen haben, hinterlassen Sie bitte eine Nachricht.

Einführung in die halbsynchrone MySQL-Replikation

(1) Standardmäßig ist die Replikationsfunktion von MySQL asynchron, was die beste Leistung bietet. Wenn die Master-Datenbank das Binlog-Protokoll an die Slave-Datenbank sendet, ist die Aktion abgeschlossen und es wird nicht überprüft, ob die Slave-Datenbank das Protokoll empfangen hat. Dieser Vorgang bedeutet, dass bei einem Ausfall des Master- oder Slave-Servers der Slave-Server das vom Master-Server gesendete Binlog-Protokoll möglicherweise nicht empfängt, was zu Dateninkonsistenzen zwischen dem Master-Server und dem Slave-Server und sogar zu Datenverlust während der Wiederherstellung führen kann.

Beachten:

Der halbsynchrone Replikationsmodus muss sowohl auf dem Master- als auch auf dem Slave-Server aktiviert sein, andernfalls verwendet der Master-Server standardmäßig den asynchronen Replikationsmodus.

(2) Fall der asynchronen Replikation:

Installations- und Konfigurationsdetails zur MySQL5.6-Datenbank-Master/Slave-Synchronisierung

(3) Um die oben genannten möglichen Fehler zu beheben, wurde in MySQL 5.5 ein halbsynchroner Replikationsmodus eingeführt. Dieser Modus stellt sicher, dass der Slave-Server die vom Master-Server gesendete binlog -Protokolldatei empfängt und in sein eigenes relay log schreibt. Anschließend gibt er dem Master-Server eine Rückmeldung, dass die Datei empfangen wurde. Erst dann kehrt der Hauptdienst-Thread zur aktuellen session zurück, um sie darüber zu informieren, dass der Vorgang abgeschlossen ist.

(4) Wenn ein Timeout auftritt, wechselt der Master-Server vorübergehend in den asynchronen Replikationsmodus, bis mindestens ein Slave-Server die Informationen rechtzeitig empfängt.

(5) Selbstreparatur von Relay-Protokollen:

Ab MySQL 5.5.X wurde der Parameter relay_log_recovery hinzugefügt. Die Funktion dieses Parameters lautet: Wenn die Slave-Slave-Datenbank abstürzt und relay.log beschädigt ist, was dazu führt, dass einige Relay-Protokolle nicht verarbeitet werden, werden alle nicht ausgeführten relay-log automatisch verworfen und die Protokolle erneut vom master abgerufen, wodurch die Integrität relay-log sichergestellt wird. Diese Funktion ist standardmäßig deaktiviert. Wenn der Wert von relay_log_recovery auf 1 gesetzt ist, kann diese Funktion in der Slave-Datenbank aktiviert werden. Es wird empfohlen, sie zu aktivieren.

(6) Umschalten zwischen halbsynchroner Replikation und asynchroner Replikation:

Das Funktionsprinzip der halbsynchronen Replikation besteht darin, dass der Slave-IO_Thread-Thread, wenn er das Binlog-Protokoll empfängt, dem Master eine Bestätigung geben muss. Wenn rpl_semi_sync_master_timeout=10000 (10 Sekunden) ist und vom Slave länger als 10 Sekunden kein Annahmebestätigungssignal empfangen wird, wechselt er automatisch in den herkömmlichen asynchronen Replikationsmodus.

MySQL halbsynchrone Replikationskonfiguration

Zuerst müssen Sie zwei MySQLs installieren, hier sind sie:

• Meister: 192.168.1.227
• Sklave: 192.168.1.224

Die ursprüngliche Datenbank sieht folgendermaßen aus:

1. Master-Konfiguration

(1) Installieren Sie das Plug-In für die halbsynchrone Replikation in der Master-Datenbank:

mysql>PLUGIN INSTALLIEREN rpl_semi_sync_master SONAME 'semisync_master.so'; 

(2) Aktivieren Sie die halbsynchrone Replikation auf dem Master:

mysql>GLOBAL rpl_semi_sync_master_enabled festlegen = 1; 

(3) Ändern Sie mysqld.cnf :

Das obige Bild zeigt den Dateipfad für die MySQL-Konfiguration.

[mysqld]

log-bin=mysql-bin
Server-ID = 10086
server_id_bits = 33
rpl_semi_sync_master_enabled=1
rpl_semi_sync_master_timeout=1000 

(4) Ändern Sie die MySQL-Server-UUID-Konfigurationsdatei:

root@xuliugen:/var/lib/mysql# pwd
/var/lib/mysql

Ändern Sie die Datei auto.cnf . Das Werteformat der server-uuid ist festgelegt, um sie vom Slave zu unterscheiden.

[Auto]
server-uuid=8d90feb7-1a88-11e7-9d11-000c298a546f

(5) Prüfen Sie, ob die Konfiguration erfolgreich war:

mysql>SELECT PLUGIN_NAME, PLUGIN_STATUS FROM INFORMATION_SCHEMA.PLUGINS WHERE PLUGIN_NAME LIKE '%semi%'; 

(6) Parameterbeschreibung:

1. rpl_semi_sync_master_enabled = 1 , zeigt an, dass der halbsynchrone Replikationsmodus auf dem Master aktiviert wurde;

2. rpl_semi_sync_master_timeout = 10000 , was bedeutet, dass, wenn die Wartezeit der Masterdatenbank bei einer Transaktion 10000 Millisekunden überschreitet, sie in den asynchronen Replikationsmodus heruntergestuft wird und nicht auf die Slavedatenbank wartet. Wenn die Master-Datenbank erkennt, dass der Slave wieder wiederhergestellt wurde, wechselt sie automatisch zurück in den halbsynchronen Replikationsmodus.

3. rpl_semi_sync_master_wait_no_slave , gibt an, ob der Master nach dem Festschreiben jeder Transaktion auf das Empfangsbestätigungssignal des Slaves warten darf. Die Standardeinstellung ist „Ein“, was bedeutet, dass jede Transaktion wartet. Wenn es AUS ist, wird der halbsynchrone Replikationsmodus nicht aktiviert, nachdem der Slave aufgeholt hat, und muss manuell aktiviert werden.

4. rpl_semi_sync_master_trace_level = 32 , was sich auf die Debugebene bezieht, die verwendet wird, wenn der halbsynchrone Replikationsmodus aktiviert ist. Der Standardwert ist 32.

Es ist ersichtlich, dass bei der Konfiguration des Masters nur 1 eingestellt wurde und die anderen auf die Standardeinstellungen gesetzt wurden.

2. Slave-Konfiguration

(1) Installieren Sie das Plug-In für die halbsynchrone Replikation in der Slave-Datenbank:

mysql>PLUGIN INSTALLIEREN rpl_semi_sync_slave SONAME 'semisync_slave.so';

(2) Aktivieren Sie die halbsynchrone Replikation auf dem Slave:

mysql>GLOBAL rpl_semi_sync_slave_enabled festlegen = 1; 

(3) Ändern Sie mysqld.cnf :

[mysqld]

log-bin=mysql-bin
server_id=10089
server_id_bits = 32
rpl_semi_sync_slave_enabled = 1 

(4) Ändern Sie die MySQL-Server-UUID-Konfigurationsdatei:

root@xuliugen:/var/lib/mysql# pwd
/var/lib/mysql

Ändern Sie die Datei auto.cnf . Das Werteformat der server-uuid ist festgelegt, um sie vom Slave zu unterscheiden.

[Auto]
server-uuid=8d90feb7-1a88-11e7-9d11-000c298a123f

Stellen Sie sicher, dass es sich von der server-uuid des Masters unterscheidet!

(5) Prüfen Sie, ob die Konfiguration erfolgreich war:

mysql>SELECT PLUGIN_NAME, PLUGIN_STATUS FROM INFORMATION_SCHEMA.PLUGINS WHERE PLUGIN_NAME LIKE '%semi%'; 

(6) Parameterbeschreibung:

1. rpl_semi_sync_slave_enabled = 1 , zeigt an, dass der halbsynchrone Replikationsmodus auf dem Slave aktiviert wurde;

2. rpl_semi_sync_slave_trace_level = 32 , was sich auf die Debugebene bezieht, die verwendet wird, wenn der halbsynchrone Replikationsmodus aktiviert ist. Der Standardwert ist 32.

3. Festlegen eines Masters für einen Slave

(1) Starten Sie den Master im Kommandozeilenmodus neu

root@xuliugen:~# service mysql restart

(2) Neustart des Slaves im Kommandozeilenmodus

root@xuliugen:~# service mysql restart

(3) Überprüfen Sie den Masterstatus:

mysql> Masterstatus anzeigen\G;
*************************** 1. Reihe ***************************
       Datei:mysql-bin.000004
     Position: 154
   Binlog_Do_DB:
 Binlog_Ignore_DB:
Ausgeführtes_Gtid_Set:
1 Zeile im Satz (0,02 Sek.)

MySQL> 

Beachten:

Datei:mysql-bin.000004
Position: 154

Ganz wichtig, du wirst es später brauchen!

(4) Geben Sie den Master für den Slave an:

1. Schalten Sie zunächst die halbsynchrone Replikation des Slaves aus

mysql> Slave stoppen;
Abfrage OK, 0 Zeilen betroffen (0,01 Sek.)

2. Master für Slave angeben

mysql>ändere Master in master_host='192.168.1.227',master_user='root',master_password='123456',master_log_file='mysql-bin.000004', master_log_pos=154;

Abfrage OK, 0 Zeilen betroffen, 2 Warnungen (0,02 Sek.)

In:

master_host='192.168.1.227', IP-Adresse der Master-Datenbankmaster_user='root', Konto der Master-Datenbankmaster_password='123456', Passwort des Root-Benutzers der Master-Datenbankmaster_log_file='mysql-bin.000004', Binärprotokolldatei der Master-Datenbankmaster_log_pos=154, Position der Binärprotokolldatei der Master-Datenbank

Beachten:

Ab MySQL Version 5.6 können Sie bei der Master-Slave-Replikation die GTID-Methode verwenden. Es ist nicht mehr nötig, Binglog- und POS-Punkte zu finden. Sie müssen nur die IP, den Port, das Konto und das Passwort des Masterservers kennen, um automatisch den Punkt für die Synchronisierung zu finden. Wenn die GTID-Funktion aktiviert ist, müssen Binlog und POS nicht mehr verwendet werden. Weitere Informationen entnehmen Sie bitte den entsprechenden Studienunterlagen.

3. Aktivieren Sie die halbsynchrone Replikation des Slaves

mysql> Slave starten;
Abfrage OK, 0 Zeilen betroffen (0,01 Sek.)

4. Testen Sie, ob die halbsynchrone Replikation erfolgreich ist

5. So schließen Sie die Slave-Synchronisierungsinformationen ordnungsgemäß

Irgendwann wird ein Server nicht mehr als Slave verwendet. Daher müssen wir seine Synchronisierungsinformationen löschen. Normalerweise geschieht dies mit:

mysql> stop slave #Zuerst herunterfahrenmysql> reset slave #Synchronisationsinformationen des Slaves löschen

Bei der Anzeige über show master status\G gilt jedoch:

mysql> Masterstatus anzeigen\G;

Die Synchronisierungsinformationen werden weiterhin angezeigt. Dies liegt daran, dass durch die Ausführung reset slave nur die Dateien „master.info“ und „relay-log.info“ gelöscht werden, die Synchronisierungsinformationen jedoch weiterhin vorhanden sind. Wenn jemand den Befehl start slave ausführt, um die Synchronisierungsfunktion einzuschalten, beginnt die Synchronisierung erneut von vorne, was zu Datenverlust führen kann.

Wie kann man es deutlicher machen? Bitte verwenden Sie den folgenden Befehl:

mysql> stop slave #Zuerst herunterfahrenmysql> reset slave all#Slave-Synchronisationsinformationen löschen

Wenn Sie show master status\G erneut ausführen, werden keine Informationen angezeigt.

VI. Simulation einiger abnormaler Szenarien

(1) Umschalten zwischen halbsynchroner Replikation und asynchroner Replikation:

Oben wurde erläutert, warum der Wechsel von der halbsynchronen Replikation zur asynchronen Replikation erfolgt. Lassen Sie uns nun zur Demonstration ein Szenario simulieren.

Das Szenario ist wie folgt:

1. Schließen Sie die Slave-Synchronisierung und stoppen Sie den IO-Empfang von Binlog-Protokollen

mysql> Slave stoppen;

Dieser Vorgang beendet den IO-Thread und wartet 10 Sekunden. Wenn der Master keine Bestätigung vom Slave erhält, wechselt er in den asynchronen Replikationsmodus:

In der obigen Abbildung können wir sehen, dass der Slave den halbsynchronen Replikationsmodus ausgeschaltet und wieder eingeschaltet hat:

mysql> Slave starten; 

An diesem Punkt wurde der halbsynchrone Replikationsmodus wiederhergestellt.

(2) Demonstration des synchronen Fehlerfalls:

Wir löschen zunächst die Datenbanktabelle ufind aus der Slave-Bibliothek und löschen anschließend die Bibliothek ufind erneut auf dem Master. Die Synchronisation meldet einen Fehler:

Last_Error: Fehler „Datenbank ‚ufind‘ kann nicht gelöscht werden; Datenbank existiert nicht“ bei Abfrage. Standarddatenbank: ‚ufind‘. Abfrage: ‚DROP DATABASE ‚ufind‘‘

Überprüfen Sie an dieser Stelle den halbsynchronen Status:

Es ist aktiviert, sodass der halbsynchrone Replikationsmodus nicht in den asynchronen Replikationsmodus umgewandelt wird. Es ist ersichtlich, dass der halbsynchrone Replikationsmodus direkt mit IO_Thread zusammenhängt, aber nichts mit SQL_THREAD zu tun hat.

Das heißt, nach dem Empfang des Binärprotokolls von der Slave-Bibliothek gibt es der Master-Bibliothek eine Bestätigung, kümmert sich jedoch nicht darum, ob relay-log Relay-Protokoll ausgeführt wird.

6. Leistungsanalyse, Vor- und Nachteile des halbsynchronen Replikationsmodus

Da der asynchrone Replikationsmodus unter normalen Umständen nicht auf die Antwort vom Server warten muss, ist seine Geschwindigkeit höher als beim halbsynchronen Replikationsmodus und sein Durchsatz ist höher. Beim Aktualisieren, Einfügen und Löschen von Daten ist seine Geschwindigkeit höher als beim halbsynchronen Replikationsmodus. Der halbsynchrone Replikationsmodus ist jedoch für die Datenkonsistenz von Vorteil. Für einige Daten mit hohen Konsistenzanforderungen und kleinen Netzwerkschwankungen kann der halbsynchrone Replikationsmodus verwendet werden.

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.