Если вы запускаете
SHOW MASTER STATUS\G
вы увидите что-то вроде этого:
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)
Поскольку GTID включен, все серверы получили свой UUID, и есть транзакции.
Я предполагаю, что вы создали дамп с помощью mysqldump, и если вы посмотрите на начало этого файла, вы найдете нечто похожее на это:
--
-- 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';
Это команда, которая не может быть выполнена.
У вас есть следующие варианты:
Удалите эту команду из файла дампа mysql. Просто удалите это. Все вставки будут отображаться на ведомом устройстве как локальные транзакции.
Если вы хотите предотвратить это, вы также можете сбросить мастер на подчиненном
mysql> RESET MASTER;
Эта команда очистит переменную «Executed_Gtid_Set» на ведомом устройстве, поэтому вы можете импортировать файл дампа напрямую, а ранее упомянутая переменная set_global_gtid_purged выполняет действие
Когда вы создаете mysqldump, вы можете пропустить часть настройки GTID, добавив
--set-GTID-продувают = OFF
параметр для mysqldump.
НОТА:
если подмножество GTID отличается на master между master и slave (если вы хотите использовать это в настройке репликации), то репликация не будет работать, я бы рекомендовал двоичный дамп и восстановление, так как GTID подчиненного устройства точно соответствует master.
С GTID возникает много новых проблем, но ваша настройка реплики будет более последовательной. С этим стоит работать.