it-swarm.com.de

Wie kann ich die Mysql-DB erneut synchronisieren, wenn Master und Slave unterschiedliche Datenbanken haben, wenn Mysql-Replikation durchgeführt wird?

Mysql Server1 läuft alsMASTER.
Mysql Server2 läuft alsSLAVE.

Jetzt erfolgt die DB-Replikation vonMASTERnachSLAVE.

Server2 wird aus dem Netzwerk entfernt und nach 1 Tag wieder verbunden. Danach gibt es keine Übereinstimmung in der Datenbank in Master und Slave.

Wie kann die DB erneut synchronisiert werden, da nach dem Wiederherstellen der DB vom Master zum Slave das Problem nicht gelöst wird?

125
Indu Sharma

Dies ist die vollständige Schritt-für-Schritt-Prozedur, um eine Master-Slave-Replikation von Grund auf neu zu synchronisieren:

Beim Meister:

RESET MASTER;
FLUSH TABLES WITH READ LOCK;
SHOW MASTER STATUS;

Und kopiere die Werte des Ergebnisses des letzten Befehls irgendwo.

Ohne die Verbindung zum Client zu beenden (da die Lesesperre aufgehoben würde), geben Sie den Befehl aus, um einen Dump des Masters abzurufen:

mysqldump -u root -p --all-databases > /a/path/mysqldump.sql

Jetzt können Sie die Sperre aufheben, auch wenn der Speicherauszug noch nicht beendet ist. Führen Sie dazu im MySQL-Client den folgenden Befehl aus:

UNLOCK TABLES;

Kopieren Sie nun die Dump-Datei mit scp oder Ihrem bevorzugten Werkzeug in den Slave.

Beim Sklaven:

Öffnen Sie eine Verbindung zu MySQL und geben Sie Folgendes ein:

STOP SLAVE;

Laden Sie den Datenauszug des Masters mit diesem Konsolenbefehl:

mysql -uroot -p < mysqldump.sql

Slave- und Master-Protokolle synchronisieren:

RESET SLAVE;
CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=98;

Die Werte der obigen Felder sind die, die Sie zuvor kopiert haben.

Geben Sie zum Schluss Folgendes ein:

START SLAVE;

Um zu überprüfen, ob alles nach der Eingabe wieder funktioniert:

SHOW SLAVE STATUS;

das solltest du sehen:

Slave_IO_Running: Yes
Slave_SQL_Running: Yes

Das ist es! 

260
David Espart

Die Dokumentation auf der MySQL-Site ist leider nicht mehr aktuell und mit Foot-Guns (wie interactive_timeout) durchsetzt. Die Ausgabe von FLUSH TABLES WITH READ LOCK als Teil des Exports des Masters ist in der Regel nur sinnvoll, wenn Sie mit einem Speicher-/Dateisystem-Snapshot wie LVM oder zfs koordiniert ist.

Wenn Sie mysqldump verwenden, sollten Sie stattdessen auf die Option --master-data zurückgreifen, um vor menschlichen Fehlern zu schützen und die Sperren auf dem Master so schnell wie möglich zu lösen.

Angenommen, der Master ist 192.168.100.50 und der Slave ist 192.168.100.51, jeder Server hat eine eigene Server-ID konfiguriert, der Master hat eine binäre Protokollierung und der Slave hat in my.cnf schreibgeschützt = 1

Geben Sie den Befehl CHANGE MASTER aus, ohne den Namen und die Position der Protokolldatei auszulassen.

slaveserver> CHANGE MASTER TO MASTER_Host='192.168.100.50', MASTER_USER='replica', MASTER_PASSWORD='asdmk3qwdq1';

Geben Sie den GRANT auf dem Master aus, den der Slave verwenden soll:

masterserver> GRANT REPLICATION SLAVE ON *.* TO 'replica'@'192.168.100.51' IDENTIFIED BY 'asdmk3qwdq1';

Exportieren Sie den Master (im Bildschirm) mit Komprimierung und automatischem Erfassen der korrekten binären Protokollkoordinaten:

mysqldump --master-data --all-databases --flush-privileges | gzip -1 > replication.sql.gz

Kopieren Sie die replication.sql.gz-Datei in den Slave und importieren Sie sie dann mit zcat in die Instanz von MySQL, die auf dem Slave ausgeführt wird:

zcat replication.sql.gz | mysql

Starten Sie die Replikation, indem Sie den Befehl an den Slave ausgeben:

slaveserver> START SLAVE;

Aktualisieren Sie optional die Datei /root/.my.cnf auf dem Slave, um dasselbe Root-Kennwort wie der Master zu speichern.

Wenn Sie 5.1 oder älter verwenden, setzen Sie am besten das binlog_format des Masters auf MIXED oder ROW. Beachten Sie, dass in Zeilen protokollierte Ereignisse für Tabellen, die keinen Primärschlüssel enthalten, langsam sind. Dies ist normalerweise besser als die alternative (und Standard-) Konfiguration der binlog_format = -Anweisung (auf Master), da es weniger wahrscheinlich ist, dass falsche Daten auf dem Slave erzeugt werden.

Wenn Sie die Replikation filtern müssen (sollten, sollten Sie dies jedoch wahrscheinlich nicht tun), verwenden Sie die Slave-Optionen replicate-wild-do-table = dbname.% Oder replicate-wild-ignore-table = badDB.% Und verwenden Sie nur die Zeile binlog_format =

Dieser Prozess hält eine globale Sperre für den Master für die Dauer des Befehls mysqldump, hat jedoch keine Auswirkungen auf den Master.

Wenn Sie versucht sind, mysqldump --master-data --all-database --single-transaction zu verwenden (weil Sie nur InnoDB-Tabellen verwenden), sind Sie möglicherweise besser mit MySQL Enterprise Backup oder der Open-Source-Implementierung namens xtrabackup (mit freundlicher Genehmigung von Percona)

23
Outdated

Wenn Sie nicht direkt an den Slave schreiben (Server2), besteht das einzige Problem darin, dass auf Server2 alle Aktualisierungen fehlen, die seit der Trennung der Verbindung geschehen sind. Starten Sie den Slave einfach mit "START SLAVE;" sollte alles wieder auf Touren bringen.

16
malonso

Ich denke, Maatkit nutzt für Sie! Sie können mk-table-sync verwenden. Bitte sehen Sie diesen Link: http://www.maatkit.org/doc/mk-table-sync.html

7
Minor

Ich bin sehr spät zu dieser Frage, obwohl ich auf dieses Problem gestoßen bin und nach langem Suchen diese Informationen von Bryan Kennedy gefunden habe: http://plusbryan.com/mysql-replication-outout-outowntime

Auf dem Master machen Sie ein Backup wie folgt:
mysqldump --skip-lock-tables --single-transaction --flush-logs --hex-blob --master-data = 2 -A> ~/dump.sql

Untersuchen Sie nun den Kopf der Datei und notieren Sie sich die Werte für MASTER_LOG_FILE und MASTER_LOG_POS. Sie werden sie später brauchen: head dump.sql -n80 | grep "MASTER_LOG"

Kopieren Sie die Datei "dump.sql" in den Slave und stellen Sie sie wieder her: mysql -u mysql-user -p <~/dump.sql

Stellen Sie eine Verbindung zu Slave mysql her und führen Sie einen Befehl wie folgt aus: CHANGE MASTER TO MASTER_Host = 'master-server-ip', MASTER_USER = 'replication-user', MASTER_PASSWORD = 'slave-server-password', MASTER_LOG_FILE = ' Wert von oben ', MASTER_LOG_POS = Wert von oben; START SKLAVE;

So überprüfen Sie den Fortschritt des Slaves: SHOW SLAVE STATUS;

Wenn alles in Ordnung ist, ist Last_Error leer und Slave_IO_State meldet "Wartet auf Master, der ein Ereignis sendet". Suchen Sie nach Seconds_Behind_Master, der angibt, wie weit dahinter. YMMV. :)

5
Jeffery7

Folgen Sie Davids Antwort ...

Die Verwendung von SHOW SLAVE STATUS\G liefert eine vom Menschen lesbare Ausgabe.

5
Greg Ackerson

Hier ist, was ich normalerweise mache, wenn ein MySQL-Slave nicht mehr synchron ist. Ich habe mir Mk-Table-Sync angesehen, dachte aber, dass der Abschnitt Risks unheimlich aussieht.

Am Meister:

SHOW MASTER STATUS

Die ausgegebenen Spalten (File, Position) werden uns in gewisser Weise nützlich sein.

Am Sklaven:

STOP SLAVE

Legen Sie dann die Master-Datenbank ab und importieren Sie sie in die Slave-Datenbank.

Führen Sie dann Folgendes aus:

CHANGE MASTER TO
  MASTER_LOG_FILE='[File]',
  MASTER_LOG_POS=[Position];
START SLAVE;

Wobei [File] und [Position] die Werte sind, die von "SHOW MASTER STATUS" ausgegeben wurden.

Hoffe das hilft!

5
Bryson

manchmal musst du dem Sklaven auch nur einen Tritt geben

versuchen

sklave stoppen;
Slave zurücksetzen;
Slave starten;
Slave Status anzeigen;

ziemlich oft, Sklaven, sie stecken nur Jungs fest :)

Hier ist eine vollständige Antwort, die hoffentlich anderen helfen wird ...


Ich möchte die Mysql-Replikation mit Master und Slave einrichten, und da ich nur wusste, dass Log-Dateien zum Synchronisieren verwendet werden, wenn der Slave offline geht und nicht mehr synchron ist, sollte er theoretisch nur eine Verbindung herstellen zu seinem Master und lesen Sie die Protokolldatei weiter von dort, wo sie aufgehört hat, wie der Benutzer malonso erwähnt hat.

Hier also das Testergebnis nach der Konfiguration des Masters und des Slaves wie erwähnt: http://dev.mysql.com/doc/refman/5.0/de/replication-howto.html ...

Vorausgesetzt, Sie verwenden die empfohlene Master/Slave-Konfiguration und schreiben nicht auf den Slave. Er und ich hatten Recht (soweit MySQL-Server 5.x betroffen ist). Ich brauchte nicht einmal "START SLAVE;", es holte einfach seinen Master ein. Es gibt jedoch einen Standardwert von 88000, der alle 60 Sekunden wiederholt wird. Wenn Sie also erschöpft sind, müssen Sie möglicherweise den Slave starten oder neu starten. Wie auch immer, für diejenigen wie mich, die wissen wollten, ob ein Sklave offline gehen und wieder Backups benötigt, muss manuell eingegriffen werden. Nein, das ist nicht der Fall.

Vielleicht war das Originalposter in den Log-Dateien beschädigt? Aber höchstwahrscheinlich nicht nur ein Server, der für einen Tag offline geht.


aus /usr/share/doc/mysql-server-5.1/README.Debian.gz gezogen, was wahrscheinlich auch für Nicht-Debian-Server Sinn macht:

* WEITERE ANMERKUNGEN ZUR REPLIKATION 
 ===============================...... Wenn der MySQL-Server als Replikationsslave, sollten Sie nicht 
 --tmpdir so einstellen, dass er auf ein Verzeichnis in einem speicherbasierten Dateisystem oder auf 
 verweist, das beim Neustart des Serverhosts gelöscht wird. Ein Replikations-Slave benötigt einige seiner temporären Dateien, um einen Neustart des Computers zu überstehen, so dass er temporäre Tabellen oder LOAD DATA INFILE-Operationen replizieren kann. Wenn 
 -Dateien im temporären Dateiverzeichnis verloren gehen, wenn der Server neu gestartet wird, schlägt die __.-Replikation fehl .

Sie können etwas wie SQL verwenden: show Variablen wie 'tmpdir'; herausfinden.

2
bksunday

Hinzufügen der populären Antwort, um diesen Fehler aufzunehmen: 

"ERROR 1200 (HY000): The server is not configured as slave; fix in config file or with CHANGE MASTER TO",

Replikation vom Slave in einem Schuss:

In einem Terminalfenster: 

mysql -h <Master_IP_Address> -uroot -p

Nach dem Verbinden

RESET MASTER;
FLUSH TABLES WITH READ LOCK;
SHOW MASTER STATUS;

Der Status wird wie folgt angezeigt: Beachten Sie, dass die Positionsnummer variiert!

+------------------+----------+--------------+------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000001 |      98  | your_DB      |                  |
+------------------+----------+--------------+------------------+

Exportieren Sie den Dump so, wie er " mit einem anderen Terminal " beschrieben hat!

Beenden Sie und stellen Sie eine Verbindung zu Ihrer eigenen DB her (die der Slave ist):

mysql -u root -p

Geben Sie die folgenden Befehle ein:

STOP SLAVE;

Importieren Sie den Dump wie erwähnt (natürlich in einem anderen Terminal!) Und geben Sie die folgenden Befehle ein:

RESET SLAVE;
CHANGE MASTER TO 
  MASTER_Host = 'Master_IP_Address', 
  MASTER_USER = 'your_Master_user', // usually the "root" user
  MASTER_PASSWORD = 'Your_MasterDB_Password', 
  MASTER_PORT = 3306, 
  MASTER_LOG_FILE = 'mysql-bin.000001', 
  MASTER_LOG_POS = 98; // In this case

Legen Sie nach dem Protokollieren den Parameter server_id fest (normalerweise für neue/nicht replizierte DBs ist dies nicht standardmäßig festgelegt). 

set global server_id=4000;

Starten Sie jetzt den Sklaven.

START SLAVE;
SHOW SLAVE STATUS\G;

Die Ausgabe sollte dieselbe sein wie er beschrieben wurde.

  Slave_IO_Running: Yes
  Slave_SQL_Running: Yes

Hinweis: Nach der Replikation teilen sich Master und Slave dasselbe Passwort!

2
curlyreggie

Umbau des Slaves mit LVM

Dies ist die Methode, mit der wir MySQL-Slaves mit Linux LVM neu erstellen. Dies garantiert eine konsistente Momentaufnahme und erfordert nur minimale Ausfallzeiten auf Ihrem Master.

Setzen Sie den Innodb Max Dirty Pages-Prozentsatz auf dem Master-MySQL-Server auf Null. Dadurch wird MySQL gezwungen, alle Seiten auf die Festplatte zu schreiben, was den Neustart erheblich beschleunigt.

set global innodb_max_dirty_pages_pct = 0;

Führen Sie den Befehl aus, um die Anzahl der fehlerhaften Seiten zu überwachen

mysqladmin ext -i10 | grep dirty

Sobald die Anzahl aufhört zu sinken, haben Sie den Punkt erreicht, um fortzufahren. Setzen Sie anschließend den Master zurück, um die alten Bin-Protokolle/Relay-Protokolle zu löschen:

RESET MASTER;

Führen Sie lvdisplay aus, um den LV-Pfad zu erhalten

lvdisplay

Die Ausgabe wird so aussehen

--- Logical volume ---
LV Path                /dev/vg_mysql/lv_data
LV Name                lv_data
VG Name                vg_mysql

Fahren Sie die Master-Datenbank mit dem Befehl herunter

service mysql stop

Machen Sie als Nächstes einen Snaphot. Als neuer Name des logischen Volumes wird mysql_snapshot verwendet. Wenn sich auf dem Betriebssystemlaufwerk Binlogs befinden, müssen diese ebenfalls ein Snapshot sein.

lvcreate --size 10G --snapshot --name mysql_snapshot /dev/vg_mysql/lv_data

Starten Sie den Master erneut mit dem Befehl

service mysql start

Stellen Sie verschmutzte Seiten auf die Standardeinstellung zurück

set global innodb_max_dirty_pages_pct = 75;

Führen Sie lvdisplay erneut aus, um sicherzustellen, dass der Schnappschuss vorhanden und sichtbar ist

lvdisplay

Ausgabe:

--- Logical volume ---
LV Path                /dev/vg_mysql/mysql_snapshot
LV Name                mysql_snapshot
VG Name                vg_mysql

Mounten Sie den Schnappschuss

mkdir /mnt/mysql_snapshot
mount /dev/vg_mysql/mysql_snapshot /mnt/mysql_snapshot

Wenn Sie einen vorhandenen MySQL-Slave haben, müssen Sie ihn stoppen

service mysql stop

Als nächstes müssen Sie den MySQL-Datenordner löschen

cd /var/lib/mysql
rm -fr *

Zurück zum Meister Jetzt synchronisieren Sie den Snapshot mit dem MySQL-Slave

rsync --progress -harz /mnt/mysql_snapshot/ targethostname:/var/lib/mysql/

Sobald rsync abgeschlossen ist, können Sie die Momentaufnahme aufheben und entfernen

umount /mnt/mysql_snapshot
lvremove -f /dev/vg_mysql/mysql_snapshot

Erstellen Sie einen Replikationsbenutzer auf dem Master, wenn der alte Replikationsbenutzer nicht vorhanden ist oder das Kennwort unbekannt ist

GRANT REPLICATION SLAVE on *.* to 'replication'@'[SLAVE IP]' identified by 'YourPass';

Vergewissern Sie sich, dass/var/lib/mysql-Datendateien dem mysql-Benutzer gehören, wenn Sie den folgenden Befehl weglassen können:

chown -R mysql:mysql /var/lib/mysql

Als nächstes notieren Sie die binlog Position

ls -laF | grep mysql-bin

Sie werden so etwas sehen

..
-rw-rw----     1 mysql mysql  1073750329 Aug 28 03:33 mysql-bin.000017
-rw-rw----     1 mysql mysql  1073741932 Aug 28 08:32 mysql-bin.000018
-rw-rw----     1 mysql mysql   963333441 Aug 28 15:37 mysql-bin.000019
-rw-rw----     1 mysql mysql    65657162 Aug 28 16:44 mysql-bin.000020

Hier ist die Master-Protokolldatei die höchste Dateinummer in der Reihenfolge und die Position des Bin-Protokolls ist die Dateigröße. Notieren Sie diese Werte:

master_log_file=mysql-bin.000020
master_log_post=65657162

Als nächstes starten Sie den Slave MySQL

service mysql start

Führen Sie den Change-Master-Befehl auf dem Slave aus, indem Sie Folgendes ausführen:

CHANGE MASTER TO 
master_Host="10.0.0.12", 
master_user="replication", 
master_password="YourPass", 
master_log_file="mysql-bin.000020", 
master_log_pos=65657162; 

Zum Schluss den Slave starten

SLAVE START;

Slave-Status prüfen:

SHOW SLAVE STATUS;

Stellen Sie sicher, dass Slave IO ausgeführt wird und keine Verbindungsfehler vorliegen. Viel Glück!

BR, Juha Vehnia

Ich habe dies kürzlich auf meinem Blog geschrieben, das hier zu finden ist ... Es gibt ein paar weitere Details, aber die Geschichte ist die gleiche.

http://www.juhavehnia.com/2015/05/rebuilding-mysql-slave-using-linux-lvm.html

0
Juha Vehnia

Wir verwenden die Master-Master-Replikationsmethode von MySQL. Wenn ein MySQL-Server sagt, dass 1 aus dem Netzwerk entfernt wird, stellt er die Verbindung wieder her, nachdem die Verbindung wiederhergestellt wurde und alle Datensätze übertragen wurden, die auf dem Server 2, der sich im Netzwerk befunden hat, übertragen wurden an den Server 1, der die Verbindung nach der Wiederherstellung verloren hat . Der Slave-Thread in MySQL versucht, standardmäßig alle 60 Sekunden eine Verbindung zu seinem Master herzustellen. Diese Eigenschaft kann geändert werden, da MySQL ein Flag "master_connect_retry = 5" hat, wobei 5 in Sekunden ist. Dies bedeutet, dass wir alle 5 Sekunden einen erneuten Versuch wünschen.

Sie müssen jedoch sicherstellen, dass der Server, auf dem die Verbindung unterbrochen wurde, keine Festschreibung in der Datenbank ausführt, da Sie einen doppelten Schlüsselfehler Fehlercode: 1062 erhalten 

0
parag gupta

Ich habe ein GitHub-Repo mit einem Skript erstellt, um dieses Problem schnell zu lösen. Ändern Sie einfach ein paar Variablen und führen Sie sie aus (Zuerst erstellt das Skript eine Sicherung Ihrer Datenbank).

Ich hoffe, das hilft Ihnen (und auch anderen Leuten).

Zurücksetzen (erneutes Synchronisieren) der MySQL Master-Slave-Replikation

0
MCurbelo