Wenn Sie einen laufen lassen
SHOW MASTER STATUS\G Sie werden so etwas sehen:
mysql> show master status\G *************************** 1. row *************************** File: mysql-bin.000299 Position: 780437462 Binlog_Do_DB: Binlog_Ignore_DB: Executed_Gtid_Set: 075d81d6-8d7f-11e3-9d88-b4b52f517ce4:1-616637650, e907792a-8417-11e3-a037-b4b52f51dbf8:1-25385296642 1 row in set (0.00 sec) Da die GTID aktiviert ist, haben alle Server ihre eigene uuid und es gibt Transaktionen. Ich nehme an, Sie haben den Dump mit mysqldump erstellt, und wenn Sie sich den Anfang dieser Datei ansehen, werden Sie etwas ähnliches wie dieses finden:
-- -- GTID state at the beginning of the backup -- SET @@GLOBAL.GTID_PURGED='075d81d6-8d7f-11e3-9d88-b4b52f517ce4:1-616648986, e907792a-8417-11e3-a037-b4b52f51dbf8:1-25385296642'; Dies ist der Befehl, der nicht ausgeführt werden kann.
Sie haben folgende Möglichkeiten:
Entfernen Sie diesen Befehl aus der mysql-Dump-Datei. Löschen Sie es einfach. Alle Einfügungen werden auf dem Slave als lokale Transaktionen angezeigt
Wenn Sie dies verhindern möchten, können Sie auch Master auf Slave zurücksetzen
mysql> RESET MASTER;
Dieser Befehl bereinigt die Variable 'Executed_Gtid_Set' auf dem Slave, sodass Sie die Dumpfile direkt importieren können und die zuvor erwähnte Variable set_global_gtid_purged aktiv wird
Wenn Sie den mysqldump erstellen, können Sie den GTID-Setup-Teil überspringen
--set-gtid-purged = OFF
Parameter für mysqldump.
HINWEIS:
Wenn sich die GTID-Untermenge auf Master zwischen Master und Slave unterscheidet (wenn Sie dies in einem Replikationssetup verwenden möchten), dann funktioniert die Replikation nicht. Ich empfehle einen binären Dump und Restore, da die GTID des Slaves genau auf den Master eingestellt ist.
Bei der GTID treten viele neue Probleme auf, aber das Replikatsetup wird konsistenter. Es lohnt sich damit zu arbeiten.