Если вы запускаете 
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 возникает много новых проблем, но ваша настройка реплики будет более последовательной. С этим стоит работать.