Wie synchronisiere ich die MySQL-Datenbank erneut, wenn Master und Slave unterschiedliche Datenbanken für die MySQL-Replikation haben?

MySQL Server1läuft als MASTER .
MySQL Server2läuft als SLAVE .

Jetzt findet die DB-Replikation von MASTER nach SLAVE statt .

Server2wird aus dem Netzwerk entfernt und nach 1 Tag wieder verbunden. Danach gibt es eine Nichtübereinstimmung in der Datenbank in Master und Slave.

Wie kann ich die Datenbank erneut synchronisieren, da nach dem Wiederherstellen der von Master zu Slave übernommenen Datenbank das Problem ebenfalls nicht gelöst wird?

Dies ist die vollständige schrittweise Anleitung zum erneuten Synchronisieren einer Master-Slave-Replikation von Grund auf neu:

Beim Meister:

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

Und kopieren Sie die Werte des Ergebnisses des letzten Befehls irgendwo hin.

Geben Sie den Befehl aus, um einen Speicherauszug des Masters abzurufen, ohne die Verbindung zum Client zu schließen (da dadurch die Lesesperre aufgehoben würde):

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 den folgenden Befehl im MySQL-Client aus:

UNLOCK TABLES;

Kopieren Sie nun die Dump-Datei mit scp oder Ihrem bevorzugten Tool auf den Slave.

Beim Sklaven:

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

STOP SLAVE;

Laden Sie den Datendump des Masters mit diesem Konsolenbefehl:

mysql -uroot -p < mysqldump.sql

Synchronisieren Sie Slave- und Master-Protokolle:

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

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

Geben Sie zum Schluss Folgendes ein:

START SLAVE;

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

SHOW SLAVE STATUS;

Das solltest du sehen:

Slave_IO_Running: Yes
Slave_SQL_Running: Yes

Das ist es!

Die Dokumentation dazu auf der MySQL-Site ist absolut veraltet und voller Fußgewehre (wie z. B. interaktives Zeitlimit). Das Ausgeben von FLUSH TABLES WITH READ LOCK als Teil Ihres Exports des Masters ist im Allgemeinen nur dann sinnvoll, wenn es mit einem Speicher- / Dateisystem-Snapshot wie LVM oder zfs koordiniert ist.

Wenn Sie mysqldump verwenden möchten, sollten Sie sich stattdessen auf die Option --master-data verlassen, um sich vor menschlichem Versagen zu schützen und die Sperren des Masters so schnell wie möglich aufzuheben.

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 Anmeldung und der Slave hat schreibgeschützt = 1 in my.cnf

Geben Sie den Befehl CHANGE MASTER ein, ohne den Namen und die Position der Protokolldatei wegzulassen, damit der Slave unmittelbar nach dem Importieren des Speicherauszugs die Replikation starten kann.

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

Stellen Sie den GRANT auf dem Master aus, damit der Slave Folgendes verwenden kann:

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

Exportieren Sie den Master (im Bildschirm) mithilfe der Komprimierung und erfassen Sie automatisch die richtigen binären Protokollkoordinaten:

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

Kopieren Sie die Datei replication.sql.gz auf 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 senden:

slaveserver> START SLAVE;

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

Wenn Sie mit 5.1+ arbeiten, ist es am besten, zuerst das binlog_format des Masters auf MIXED oder ROW zu setzen. Beachten Sie, dass zeilenprotokollierte Ereignisse für Tabellen ohne Primärschlüssel langsam sind. Dies ist normalerweise besser als die alternative (und Standard-) Konfiguration der Anweisung binlog_format = (auf dem Master), da es weniger wahrscheinlich ist, dass die falschen Daten auf dem Slave erzeugt werden.

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

Dieser Prozess hält eine globale Sperre für den Master für die Dauer des Befehls mysqldump, wirkt sich jedoch nicht auf den Master aus.

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

Sofern Sie nicht direkt auf den Slave (Server2) schreiben, sollte das einzige Problem darin bestehen, dass auf Server2 keine Updates fehlen, die seit dem Trennen der Verbindung aufgetreten sind. Starten Sie den Slave einfach mit "START SLAVE" neu. sollte alles wieder auf den neuesten Stand bringen.

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

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

Erstellen Sie auf dem Master 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 die Werte für MASTER_LOG_FILE und MASTER_LOG_POS. Sie werden sie später benötigen: head dump.sql -n80 | grep "MASTER_LOG"

Kopieren Sie die Datei "dump.sql" in 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 = 'Replikationsbenutzer', MASTER_PASSWORD = 'Slave-Server-Passwort', MASTER_LOG_FILE = 'Wert von oben', MASTER_LOG_POS = Wert von oben; START SLAVE;

So überprüfen Sie den Fortschritt von Slave: SHOW SLAVE STATUS;

Wenn alles in Ordnung ist, ist Last_Error leer und Slave_IO_State meldet "Warten auf das Senden des Ereignisses durch den Master". Suchen Sie nach Seconds_Behind_Master, das angibt, wie weit dahinter liegt. YMMV. :) :)

Folgendes mache ich normalerweise, wenn ein MySQL-Slave nicht mehr synchron ist. Ich habe mir mk-table-sync angesehen, fand aber, dass der Abschnitt Risiken beängstigend aussah.

Auf dem Meister:

SHOW MASTER STATUS

Die ausgegebenen Spalten (Datei, Position) werden uns in Kürze von Nutzen sein.

Auf Slave:

STOP SLAVE

Speichern Sie dann die Master-Datenbank 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 [Datei] und [Position] die Werte sind, die vom oben gezeigten "SHOW MASTER STATUS" ausgegeben wurden.

Hoffe das hilft!

Davids Antwort nachverfolgen ...

Wenn Sie verwenden SHOW SLAVE STATUS\G, erhalten Sie eine lesbare Ausgabe.

Manchmal muss man dem Sklaven auch nur einen Tritt geben

Versuchen

stop slave;    
reset slave;    
start slave;    
show slave status;

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

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

Ich möchte die MySQL-Replikation mit Master und Slave einrichten. Da ich nur wusste, dass zur Synchronisierung Protokolldateien verwendet werden, sollte der Slave theoretisch nur eine Verbindung herstellen müssen, wenn er offline geht und nicht mehr synchron ist zu seinem Master und lesen Sie die Protokolldatei weiter, wo sie aufgehört hat, wie der Benutzer malonso erwähnt hat.

Hier sind die Testergebnisse nach der Konfiguration von Master und Slave wie folgt: http://dev.mysql.com/doc/refman/5.0/en/replication-howto.html ...

Vorausgesetzt, Sie verwenden die empfohlene Master / Slave-Konfiguration und schreiben nicht an den Slave, er und ich, wo es richtig ist (soweit es MySQL-Server 5.x betrifft). Ich brauchte nicht einmal "START SLAVE" zu verwenden, es holte nur seinen Meister ein. Aber es gibt einen Standardwert von 88000, der alle 60 Sekunden wiederholt wird. Wenn Sie also erschöpft sind, müssen Sie den Slave möglicherweise starten oder neu starten. Wie auch immer, für diejenigen wie mich, die wissen wollten, ob ein Slave, der offline und wieder gesichert wird, manuelle Eingriffe erfordert. Nein, das tut es nicht.

Möglicherweise war das Originalposter in den Protokolldateien 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 sinnvoll ist:

* WEITERE HINWEISE ZUR REPLIKATION
===============================
Wenn der MySQL-Server als Replikations-Slave fungiert, sollten Sie dies nicht tun
Setzen Sie --tmpdir so, dass es auf ein Verzeichnis in einem speicherbasierten Dateisystem verweist oder auf
Ein Verzeichnis, das beim Neustart des Serverhosts gelöscht wird. Eine Replikation
Der Slave benötigt einige seiner temporären Dateien, um einen Neustart des Computers zu überstehen
dass es temporäre Tabellen oder LOAD DATA INFILE-Operationen replizieren kann. Wenn
Dateien im temporären Dateiverzeichnis gehen beim Neustart des Servers verloren.
Replikation schlägt fehl.

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

Hinzufügen zu der beliebten Antwort, um diesen Fehler einzuschließen:

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

Replikation vom Slave auf einen Schlag:

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 sieht wie folgt aus: Beachten Sie, dass die Positionsnummer variiert!

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

Exportieren Sie den Dump ähnlich wie er es " mit einem anderen Terminal " beschrieben hat!

Beenden Sie und stellen Sie eine Verbindung zu Ihrer eigenen Datenbank 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 ein anderes 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 der Protokollierung den Parameter server_id fest (normalerweise wird dieser für neue / nicht replizierte DBs nicht standardmäßig festgelegt).

set global server_id=4000;

Starten Sie jetzt den Slave.

START SLAVE;
SHOW SLAVE STATUS\G;

Die Ausgabe sollte die gleiche sein, wie er beschrieben hat.

  Slave_IO_Running: Yes
  Slave_SQL_Running: Yes

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

Neuerstellung des Slaves mit LVM

Hier ist die Methode, mit der wir MySQL-Slaves unter Linux LVM neu erstellen. Dies garantiert einen konsistenten Schnappschuss und erfordert nur minimale Ausfallzeiten Ihres Masters.

Setzen Sie innodb max schmutzige Seiten Prozent 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 Zahl nicht mehr abnimmt, haben Sie den Punkt erreicht, an dem Sie fortfahren können. Setzen Sie als Nächstes 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 abzurufen

lvdisplay

Die Ausgabe sieht folgendermaßen aus

--- 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

Nehmen Sie als nächstes ein Snaphot, mysql_snapshot ist der neue logische Datenträgername. Wenn sich Binlogs auf dem Betriebssystemlaufwerk befinden, müssen diese ebenfalls als Snapshot erstellt werden.

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 die Standardeinstellung für schmutzige Seiten auf die Standardeinstellung zurück

set global innodb_max_dirty_pages_pct = 75;

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

lvdisplay

Ausgabe:

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

Hängen Sie den Schnappschuss ein

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

Wenn ein MySQL-Slave ausgeführt wird, 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. Synchronisieren Sie nun den Snapshot mit dem MySQL-Slave

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

Sobald rsync abgeschlossen ist, können Sie den Snapshot aushängen 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';

Stellen Sie sicher, dass die Datendateien / var / lib / mysql dem Benutzer mysql gehören. In diesem Fall können Sie den folgenden Befehl weglassen:

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

Zeichnen Sie als nächstes die Binlog-Position auf

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 Folge 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 Befehl change master 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; 

Starten Sie endlich den Slave

SLAVE START;

Slave-Status überprü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 in meinem Blog geschrieben, der hier zu finden ist ... Es gibt dort nur wenige Details, aber die Geschichte ist dieselbe.

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

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

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

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

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

Sie müssen jedoch sicherstellen, dass der Server, der die Verbindung verloren hat, kein Commit in der Datenbank ausführt, da Sie einen doppelten Schlüsselfehler erhalten. Fehlercode: 1062

Meister :

mysqldump -u root -p --all-databases --master-data | gzip > /tmp/dump.sql.gz  

scp master:/tmp/dump.sql.gz slave:/tmp/ Verschieben Sie die Dump-Datei auf den Slave-Server

Sklave:

STOP SLAVE;

zcat /tmp/dump.sql.gz | mysql -u root -p

START SLAVE;
SHOW SLAVE STATUS;  

HINWEIS :
Auf dem Master können Sie SET GLOBAL expire_logs_days = 3bei Slave-Problemen 3 Tage lang Binlogs aufbewahren.