Die Gründe, warum MySQL-Master und -Slave synchronisiert sind: 1. Netzwerkverzögerung; 2. Die Auslastung der Master- und Slave-Maschinen ist inkonsistent. 3. Die Einstellung „max_allowed_packet“ ist inkonsistent -Inkrementschlüssel unterscheidet sich vom Autoinkrementschritt. Inkonsistente Einstellungen 5. Inkonsistente Datenbankversionen usw.
Die Betriebsumgebung dieses Tutorials: Windows7-System, MySQL8-Version, Dell G3-Computer.
Analyse der Gründe für die MySQL-Master-Slave-Synchronisation
1. Netzwerkverzögerung
Da es sich bei der MySQL-Master-Slave-Replikation um eine asynchrone Replikation basierend auf Binlog handelt, werden Binlog-Dateien über das Netzwerk übertragen Natürlich ist die Netzwerkverzögerung der Hauptfaktor. Die meisten Gründe für die Nichtsynchronisierung, insbesondere die maschinenraumübergreifende Datensynchronisierung, sind sehr wahrscheinlich. Achten Sie daher bei der Trennung von Lesen und Schreiben auf das frühe Design der Geschäftsschicht.
2. Die Lasten der Master- und Slave-Maschinen sind inkonsistent
Weil die MySQL-Master-Slave-Replikation 1 IO-Thread in der Master-Datenbank startet und 1 SQL-Thread und 1 IO-Thread von oben auf jeder der Maschinen startet Die Auslastung ist sehr hoch und die Threads sind zu ausgelastet. Daher verfügt jeder Thread über unzureichende Ressourcen und es kommt zu einer Master-Slave-Inkonsistenz.
3. Max_allowed_packet-Einstellungen sind inkonsistent
Der in der Master-Datenbank festgelegte max_allowed_packet ist größer als der in der Slave-Datenbank. Wenn eine große SQL-Anweisung in der Master-Datenbank ausgeführt werden kann, ist die Einstellung in der Slave-Datenbank zu klein und kann nicht ausgeführt werden, was zum Ausfall der Masterdatenbank führt. Niemals inkonsistent.
4. Der Schlüsselwert ausgehend von der Taste für die automatische Inkrementierung stimmt nicht mit der Einstellung für die automatische Inkrementierung überein, was zu einer Master-Slave-Inkonsistenz führt.
5. Wenn MySQL ungewöhnlich ausgefallen ist und sync_binlog=1 oder innodb_flush_log_at_trx_commit=1 nicht gesetzt ist, ist es sehr wahrscheinlich, dass die Binlog- oder Relaylog-Datei beschädigt wird, was zu einer Master-Slave-Inkonsistenz führt.
6. Die Master-Slave-Synchronisation wird durch einen Fehler in MySQL selbst verursacht.
7. Datenbankversionen sind inkonsistent, insbesondere wenn die höhere Version der Master und die niedrigere Version der Slave ist, werden die von der Master-Datenbank unterstützten Funktionen nicht von der Slave-Datenbank unterstützt.
Lösung
Methode 1: Ignorieren Sie den Fehler und fahren Sie mit der Synchronisierung fort
Diese Methode eignet sich für Situationen, in denen die Daten in der Master-Slave-Datenbank nicht sehr unterschiedlich sind oder die Daten nicht unterschiedlich sein müssen völlig einheitlich und die Datenanforderungen sind nicht streng Situation
Lösung:
stop slave;
bedeutet, dass ein Schrittfehler übersprungen wird, die folgende Zahl ist variabel
set global sql_slave_skip_counter =1; start slave;
Dann verwenden Sie mysql> show Slave StatusG, um zu überprüfen:
Slave_IO_Running: Yes Slave_SQL_Running: Yes
ok, jetzt der Master -Slave-Synchronisierungsstatus ist normal. . .
Methode 2: Master-Slave neu erstellen, vollständige Synchronisierung
Diese Methode eignet sich für Situationen, in denen die Daten in der Master-Slave-Datenbank sehr unterschiedlich sind oder die Daten vollständig vereinheitlicht werden müssen
Die Die Lösungsschritte lauten wie folgt:
1. Geben Sie zuerst die Master-Datenbank ein und führen Sie „Sperren Sie die Tabelle aus, um das Schreiben von Daten zu verhindern“ aus.
Verwenden Sie den Befehl:
mysql> flush tables with read lock;
Hinweis: Dieser Ort ist im schreibgeschützten Zustand gesperrt Bei den Anweisungen wird die Groß-/Kleinschreibung nicht beachtet
2. Sichern Sie die Daten in der Datei mysql.bak.sql
mysqldump -uroot -p -hlocalhost > mysql.bak.sql
Hinweis: Die Datenbanksicherung muss regelmäßig durchgeführt werden. Sie können ein Shell-Skript oder ein Python-Skript verwenden , die bequemer sind und sicherstellen, dass die Daten narrensicher sind
3. Überprüfen Sie den Master-Status
mysql> show master status; +-------------------+----------+--------------+-------------------------------+ | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | +-------------------+----------+--------------+-------------------------------+ | mysqld-bin.000001 | 3260 | | mysql,test,information_schema | +-------------------+----------+--------------+-------------------------------+ 1 row in set (0.00 sec)
4. Übertragen Sie die MySQL-Sicherungsdatei auf den Slave-Computer und führen Sie die Datenwiederherstellung durch. Verwenden Sie den scp-Befehl den Status der Slave-Bibliothek
scp mysql.bak.sql root@192.168.128.101:/tmp/
6. Führen Sie dann den MySQL-Befehl aus der Slave-Bibliothek aus und importieren Sie die Datensicherung
mysql> Quelle /tmp/mysql.bak.sql
7. Richten Sie die Slave-Synchronisierung ein der Synchronisationspunkt dort, das sind die beiden Elemente |
Das obige ist der detaillierte Inhalt vonWas sind die Gründe, warum MySQL-Master und -Slave synchronisiert sind?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!