我想在启用了gtid的情况下创建到Percona服务器的副本，但在显示从属状态时出现此错误：
Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs containing GTIDs that the slave requires.'
通常，我会停止我的从机，重置它，重置主机（在从机上），并从主机获取新的gtid_清除值。但这一次，大师有一个非常不寻常的价值，我不知道如何确定使用哪一个：
mysql> show master status\G
*************************** 1. row ***************************
File: mysqld-bin.000283
Position: 316137263
Binlog_Do_DB:
Binlog_Ignore_DB:
Executed_Gtid_Set: 1570dee1-165b-11e6-a4a2-00e081e93212:1-3537,
c73f3ee7-e8d4-ee19-6507-f898a9930ccd:1-18609,
cdb70eaa-f753-ee1b-5c95-ecb8024ae729:1-2357789559:2357789561-2357790104:2357790106-2514115701:2514115703-2514115705:2514115707-2546512667
1 row in set (0.00 sec)
从带有新备份副本的从属服务器，我得到：
root@ubuntu:/var/lib/mysql# cat xtrabackup_binlog_info
mysqld-bin.000283 294922064 1570dee1-165b-11e6-a4a2-00e081e93212:1-3537,
c73f3ee7-e8d4-ee19-6507-f898a9930ccd:1-18609,
cdb70eaa-f753-ee1b-5c95-ecb8024ae729:1-2357789559:2357789561-2357790104:2357790106-2514115701:2514115703-2514115705:2514115707-2546400960
还有一件事，我只是在备份之前清除了主服务器上的二进制日志。自动binlog清除设置为7天。所以我知道这并不是因为bin日志已经被清除，正如错误所暗示的那样。
我运行的是ubuntu 14:04和percona服务器版本5.6.31-77。
我怎样才能解决这个问题？清除的主gtid的正确值是多少？
最佳答案
mysql 5.6 gtid复制错误及修复
什么是GTID？γ
4c2ad77f-697e-11e3-b2c3-c80aa9f17dc4
这是服务器的128位标识号（服务器ID）。它标识事务的发起位置。每台服务器都有自己的服务器ID。
GTID解决了哪些问题？
可以跨复制服务器唯一地标识事务。使故障转移过程的自动化更加容易。不需要进行计算、检查二进制日志等。只需掌握自动位置=1。
在应用程序级别，更容易进行写/读拆分。在主服务器上写入之后，就有了一个gtid，所以只需检查该gtid是否已在用于读取的从服务器上执行。
开发新的自动化工具现在不是一件痛苦的事。
我如何实现它？
复制链的所有服务器都需要三个变量
GTID_模式：它可以是开或关（不是1或0）。它在服务器上启用gtid。
log_bin:启用二进制日志。必须创建复制环境。
日志从更新：从服务器必须将来自主服务器的更改记录在其自己的二进制日志中。
强制gtid一致性：服务器拒绝不能以事务安全方式记录的语句。
参考：http://dev.mysql.com/doc/refman/5.6/en/replication-gtids-howto.html
复制错误和修复：
“'got fatal error 1236 from master when reading data from binary log:”从机使用change master to master_auto_position=1连接，但主机已清除包含从机所需GTID的二进制日志。“从机线程停止运行。
解决方案：考虑到以下是主从uuid的
MASTER UUID: 4c2ad77f-697e-11e3-b2c3-c80aa9f17dc4
SLAVE UUID: 5b37def1-6189-11e3-bee0-e89a8f22a444
步骤：
slave>stop slave;
slave> FLUSH TABLES WITH READ LOCK;
slave>show master status;
'4c2ad77f-697e-11e3-b2c3-c80aa9f17dc4:1-83345127,5b37def1-6189-11e3-bee0-e89a8f22a444:1-13030:13032-13317:13322-13325:13328-653183:653185-654126:654128-1400817:1400820-3423394:3423401-5779965′
(HERE 83345127 Last GTID executed on master and 5779965 Last slave GTID executed on Master )
slave> reset master;
slave>set global GTID_PURGED='4c2ad77f-697e-11e3-b2c3-c80aa9f17dc4:1-83345127,5b37def1-6189-11e3-bee0-e89a8f22a444:1-5779965′;
slave>start slave;
slave>unlock tables;
slave>show slave status;
注：在此之后，如果其他链从机停止复制，则重新启动从机；
错误：查询时“error”table…“不存在”。默认数据库：…查询：“insert into or last_sql_error:….error'duplicate entry'跳过从机上的事务（从机SQL线程停止运行）注意：
SQL_slave_skip_计数器在GTID下不再工作。
我们需要找到导致复制失败的事务。
–来自二进制日志
–从显示从属状态（检索到vs执行）
错误类型：（检查show slave status中的最后一个sql错误）
解决方案：考虑到以下是主从uuid的
MASTER UUID: 4c2ad77f-697e-11e3-b2c3-c80aa9f17dc4
SLAVE UUID: 5b37def1-6189-11e3-bee0-e89a8f22a444
从机>显示从机状态；
复制“executed_gtid_set”值。4C2AD77F-697E-11E3-B2C3-C80AA9F17DC4:1-659731804，5B37DEF1-6189-11E3-BEE0-E89A8F22A444:1-70734947-80436012:80436021-80437839'
-似乎是slave（带uuid 5b37def1-6189-11e3-bee0-e89a8f22a444）事务“80437840”导致了这里的问题。
slave> STOP SLAVE;
slave> SET GTID_NEXT="5b37def1-6189-11e3-bee0-e89a8f22a444:80437840"; (last_executed_slave_gtid_on_master + 1)
slave> BEGIN; COMMIT;
slave> SET GTID_NEXT="AUTOMATIC";
slave> START SLAVE;
slave> show slave status;
一切都准备好了！！！！
关于mysql - MySQL错误1236使用GTID时，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/38390765/