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. 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: 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 Erklärung der Rolle des Schlüssels in React
>>: Warum sollten Sie mit der add_header-Direktive von Nginx vorsichtig sein?
Unterabfrageklassifizierung Klassifizierung nach ...
Inhaltsverzeichnis Tutorial-Reihe 1. Beschreibung...
Manchmal erfordert die lokale Entwicklung das Deb...
Inhaltsverzeichnis 1. Einführung in den Implement...
Die meisten der folgenden Befehle müssen in der K...
Um Als ich kürzlich Vue lernte, schrieb ich ein k...
Inhaltsverzeichnis 1. Commonjs-Exporte und erford...
Schauen wir uns zunächst ohne Umschweife die Rend...
Grundaufbau: Code kopieren Der Code lautet wie fol...
Fallstricke bei der Projektimplementierung Beim B...
Vorwort In diesem Artikel wird hauptsächlich erlä...
1. Einfache Konfiguration der dynamischen und sta...
Alle Voraussetzungen erfordern Root-Berechtigunge...
Inhaltsverzeichnis Vorwort MySQL Master-Slave-Rep...
Inhaltsverzeichnis 1. Oberflächliches Klonen 2. T...