Se você executar um
SHOW MASTER STATUS\G
você verá algo assim:
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)
Quando o GTID é ativado, todos os servidores recebem seu próprio uuid e há transações. Eu suponho que você criou o dump com o mysqldump, e se você olhar para o começo desse arquivo, você encontrará algo similar como este:
--
-- 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';
Este é o comando que não pode ser executado.
Você tem as seguintes opções:
-
Remova este comando do arquivo mysql dump. Simplesmente apague-o. Todas as inserções aparecerão no escravo, pois são as transações locais
-
Se você quiser evitar que isso aconteça, você também pode redefinir o mestre no escravo
mysql > RESET MASTER;
Este comando irá limpar a variável 'Executed_Gtid_Set' no slave, para que você possa importar o dumpfile diretamente, e a variável set_global_gtid_purged mencionada anteriormente tome uma ação
-
Quando você cria o mysqldump, você pode pular a parte de configuração do GTID como adicionando o
- set-gtid-purged = OFF
para mysqldump.
NOTA:
se o subconjunto GTID for diferente no mestre entre mestre e escravo (se você quiser usar isso em uma configuração de replicação), a replicação não funcionará, eu recomendaria um despejo binário e uma restauração, definindo o GTID do escravo exatamente como o mestre.
Com o GTID, surgem muitos novos problemas, mas a configuração da sua réplica será mais consistente. Vale a pena trabalhar com isso.