MySQL 5.7.18 Master-Slave-Replikations-Setup (ein Master und ein Slave) Tutorial mit ausführlicher Erklärung

MySQL 5.7.18 Master-Slave-Replikations-Setup (ein Master und ein Slave) Tutorial mit ausführlicher Erklärung

1. Replikationsprinzip

Der Masterserver schreibt Aktualisierungen in binäre Protokolldateien und verwaltet einen Index der Dateien, um Protokollrotationen zu verfolgen. Diese Protokolle zeichnen an Slave-Server gesendete Updates auf. Wenn ein Slave eine Verbindung zu einem Master herstellt, benachrichtigt er den Master im Protokoll über den Speicherort des letzten erfolgreichen Updates, das der Slave gelesen hat. Der Slave empfängt ab diesem Zeitpunkt alle auftretenden Updates, blockiert dann und wartet auf die Benachrichtigung über neue Updates vom Master.

MySQL verwendet drei Threads, um Replikationsfunktionen auszuführen (einen auf dem Master und zwei auf den Slaves). Wenn START SLAVE ausgegeben wird, erstellt der Slave einen E/A-Thread, um eine Verbindung zum Master herzustellen und Anweisungen zu senden, die in seinem Binärprotokoll aufgezeichnet sind. Der Master erstellt einen Thread, um den Inhalt des Binärprotokolls an den Slave zu senden.

Dieser Thread ist der Binlog-Dump-Thread auf dem primären Server. Der E/A-Thread des Slave-Servers liest den vom Binlog-Dump-Thread des Master-Servers gesendeten Inhalt und kopiert die Daten in eine lokale Datei im Datenverzeichnis des Slave-Servers, nämlich das Relay-Protokoll. Der dritte Thread ist der SQL-Thread, der vom Slave-Server erstellt wird, um das Relay-Protokoll zu lesen und die im Protokoll enthaltenen Aktualisierungen auszuführen.

2. Servervorbereitung

Betriebssystemversion: Red Hat Enterprise Linux Server Version 6.7 (Santiago)

Master-IP: 172.16.115.245 Hostname: mysql2 Server-ID: 245

Slave-IP: 172.16.115.247 Hostname: mysql3 Server-ID: 247

MySQL 5.7.18 wurde sowohl auf dem Master- als auch auf dem Slave-Server installiert

3. Implementierungsdetails zur Master-Slave-Replikation

1. Richten Sie auf dem Masterserver ein Verbindungskonto für den Server ein und erteilen Sie ihm die Berechtigung REPLICATION SLAVE.

GRANT REPLICATION SLAVE ON *.* AN ‚repl‘@‚%‘ IDENTIFIZIERT DURCH ‚repl@20170509‘;

2. Ändern Sie die Masterkonfigurationsdatei my.cnf

Server-ID = 245
log_bin = /data/mysqllog/3306/bin_log/binlog

Diese beiden Werte müssen festgelegt werden. Starten Sie MySQL nach dem Festlegen neu.

3. Sichern Sie die gesamten Daten auf dem Master

mysqldump -uroot -p'password' --master-data=2 --single-transaction -R --triggers -A > /backup/all.sql

veranschaulichen:

--master-data=2 bedeutet, dass die Binlog-Position und die Position des Masters zum Zeitpunkt der Sicherung aufgezeichnet werden.
--single-transaction bedeutet, einen konsistenten Snapshot zu erhalten
-R bedeutet, gespeicherte Prozeduren und Funktionen zu sichern
--triggres bedeutet Backup-Trigger
-A bedeutet, alle Bibliotheken zu sichern

4. Überprüfen Sie den Namen und den Speicherort des Binlogs, wenn Sie die Hauptbibliothek sichern

MASTER-STATUS ANZEIGEN;
mysql> MASTER-STATUS ANZEIGEN;
+---------------+----------+-------------+------------------+-------------------+
| Datei | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+---------------+----------+-------------+------------------+-------------------+
| binlog.000004 | 79394496 | | | |
+---------------+----------+-------------+------------------+-------------------+

Oder gehen Sie zur Datenbankdatei, die Sie gerade gesichert haben, und sehen Sie sie sich an: vi all.sql

5. Ändern Sie die Konfigurationsdatei der Slave-Bibliothek my.cnf

Server-ID = 247 (eindeutig, darf nicht mit der Hauptdatenbank identisch sein, normalerweise auf die letzten 3 Ziffern der Server-IP eingestellt)
log_bin = /data/mysql/logdir/3306/bin_log/binlog
innodb_file_per_table = EIN
skip_name_resolve = EIN
relay_log = /data/mysql/logdir/3306/relay_log/relay.log
Binlog-Format = Zeile
log-slave-updates = wahr

read_only=ON (Nur-Lese-Modus)

Starten Sie MySQL nach der Festlegung neu.

6. Wiederherstellen des Master-Backups auf dem Slave-Server

mysql -u root -p 'Passwort' < all.sql

7. Stoppen Sie die Slave-Bibliothek, konfigurieren Sie die Master-Slave-Parameter und öffnen Sie die Slave-Bibliothek.

mysql> Slave stoppen; #Slave stoppenmysql>MASTER ÄNDERN IN MASTER_HOST='172.16.115.245',MASTER_USER='repl', MASTER_PASSWORD='repl@20170509',MASTER_LOG_FILE='binlog.000004',MASTER_LOG_POS=154;
mysql> start slave; #Replikation startenmysql> show slave status\G
*************************** 1. Reihe ***************************
Slave_IO_State: Wartet darauf, dass der Master ein Ereignis sendet
Master_Host: 172.16.115.245
Master_Benutzer: repl
Master_Port: 3306
Verbindungswiederholung: 60
Master_Log_File: binlog.000004
Read_Master_Log_Pos: 104634190
Relay_Log_Datei: relay.000003
Relay_Log_Pos: 104632819
Relay_Master_Log_File: binlog.000004
Slave_IO_Running: Ja
Slave_SQL_Running: Ja
Replicate_Do_DB: 
Replikat_Ignorieren_DB: 
Tabelle_replizieren: 
Tabelle_Ignorieren_replizieren: 
Wild_Do_Tabelle replizieren: 
Tabelle_Wild_Ignore_replizieren: 
Last_Errno: 0
Letzter_Fehler: 
Skip_Counter: 0
Exec_Master_Log_Pos: 104634190
Relay_Log_Space: 104634713
Until_Condition: Keine
Bis_Log_Datei: 
Bis_Log_Pos: 0
Master_SSL_Allowed: Nein
Master_SSL_CA_Datei: 
Master_SSL_CA_Pfad: 
Master_SSL_Zertifikat: 
Master_SSL_Chiffre: 
Master_SSL_Schlüssel: 
Sekunden_Hinter_Master: 0
Master_SSL_Verify_Server_Cert: Nein
Last_IO_Errno: 0
Letzter_E/A-Fehler: 
Last_SQL_Errno: 0
Letzter_SQL_Fehler: 
Server-IDs replizieren_ignorieren: 
Master_Server_Id: 245
Master_UUID: 4f545573-3170-11e7-b903-000c29462d8c
Master_Info_Datei: /data/mysql/datadir/3306/data/master.info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Slave hat alle Relay-Logs gelesen; wartet auf weitere Updates
Master_Retry_Count: 86400
Master_Bind: 
Zeitstempel des letzten IO-Fehlers: 
Letzter_SQL_Fehler_Zeitstempel: 
Master_SSL_Crl: 
Master_SSL_Crlpfad: 
Abgerufenes_Gtid_Set: 
Ausgeführtes_Gtid_Set: 
Auto_Position: 0
DB replizieren_neu schreiben: 
Kanalname: 
Master_TLS_Version:

8. Master- und Slave-bezogene Prozesse anzeigen

Master-Binlog-Dump-Thread:

mysql> PROZESSLISTE ANZEIGEN \G
*************************** 1. Reihe ***************************
ID: 13
Benutzer: repl
Gastgeber: 172.16.115.247:44602
db: NULL
Befehl: Binlog Dump
Zeit: 76514
Status: Der Master hat das gesamte Binärprotokoll an den Slave gesendet und wartet auf weitere Aktualisierungen.
Info: NULL

Slave-IO/SQL-Thread:

mysql> PROZESSLISTE ANZEIGEN \G
*************************** 1. Reihe ***************************
ID: 10
Benutzer: Systembenutzer
Gastgeber: 
db: NULL
Befehl: Verbinden
Zeit: 81148
Status: Wartet darauf, dass der Master ein Ereignis sendet
Info: NULL
*************************** 2. Reihe ***************************
ID: 12
Benutzer: Systembenutzer
Gastgeber: 
db: NULL
Befehl: Verbinden
Zeit: 5
Status: Ereignis aus dem Relay-Log lesen
Info: NULL

9. An diesem Punkt ist die Master-Slave-Konfiguration abgeschlossen. Sie können Datenbanken, Tabellen und andere Vorgänge auf dem Master-Server erstellen, um zu sehen, ob die Slave-Datenbank synchronisiert ist!

Zusammenfassen

Oben finden Sie ein ausführliches Tutorial zum Erstellen einer MySQL 5.7.18 Master-Slave-Replikation (ein Master und ein Slave), das vom Herausgeber vorgestellt wurde. Ich hoffe, es wird allen helfen. Wenn Sie Fragen haben, hinterlassen Sie mir bitte eine Nachricht und der Herausgeber wird Ihnen rechtzeitig antworten!

Das könnte Sie auch interessieren:
  • Detaillierte Erläuterung der MySQL Master-Slave-Datenbankkonstruktionsmethode
  • Verwenden von Docker-Containern zum Erstellen einer MySql-Master-Slave-Replikation
  • Tutorial zum Erstellen einer Master-Slave-Replikationsarchitektur für MySQL 5.7 Docker
  • Detaillierte Erläuterung der Konstruktion der Lese-/Schreibtrennung bei der MySQL-Master-Slave-Replikation
  • Implementierungsschritte zum Erstellen einer MySQL Master-Slave-Replikationsumgebung basierend auf Docker
  • Implementierungsideen und Schritte für die MySQL-Master-Slave-Konstruktion (mehrere Master und ein Slave)

<<:  Detaillierte Erklärung der Rolle des Schlüssels in React

>>:  Warum sollten Sie mit der add_header-Direktive von Nginx vorsichtig sein?

Artikel empfehlen

Detailliertes Beispiel einer MySQL-Unterabfrage

Unterabfrageklassifizierung Klassifizierung nach ...

MySQL Serie 12 Backup und Wiederherstellung

Inhaltsverzeichnis Tutorial-Reihe 1. Beschreibung...

Erfahren Sie mehr über den MySQL-Ausführungsplan

Inhaltsverzeichnis 1. Einführung in den Implement...

Zusammenfassung gängiger Befehle für Ubuntu-Server

Die meisten der folgenden Befehle müssen in der K...

Verwendung und Unterschied von Js-Modulverpackungsexporten erfordern Import

Inhaltsverzeichnis 1. Commonjs-Exporte und erford...

Beispielcode zur Implementierung eines 3D-Bucheffekts mit CSS

Schauen wir uns zunächst ohne Umschweife die Rend...

Anweisungen zur Verwendung des HTML-Tags dl dt dd

Grundaufbau: Code kopieren Der Code lautet wie fol...

So richten Sie den Start einer JAR-Anwendung unter CentOS7 ein

Fallstricke bei der Projektimplementierung Beim B...

Beispielcode für Nginx zur Erreichung dynamischer und statischer Trennung

1. Einfache Konfiguration der dynamischen und sta...

Detaillierte Erklärung der MySQL-Halbsynchronisierung

Inhaltsverzeichnis Vorwort MySQL Master-Slave-Rep...

Ein kurzer Vortrag über das Klonen von JavaScript

Inhaltsverzeichnis 1. Oberflächliches Klonen 2. T...