昨天处理了一个MySQL 5.6版本下开启GTID模式复制异常案例,主人上的任何操作都无法在奴隶上应用,奴隶的中继日志里有记录,但奴隶的BINLOG却找不到蛛丝马迹,由于开启了GTID,所以排查起来也简单,只需要在奴隶上把中继日志和BINLOG分别解析成文本文件,再直接搜索主的UUID,就能找的到奴隶上是否应用了主复制过来的事务。排查过程中,曾经一度怀疑是因为设置了BINLOG-DO或者忽略规则,或者设置了REPLICATION-DO或忽略规则,甚至是GTID的严重错误,但都没发现端倪。直到从显示奴隶状态里发现下面这个信息:
此处-
<李>
李
-
<李>
正常滴,在MySQL 56启用GTID后,部署复制复制时,可以设定MASTER_AUTO_POSITION 1,让奴隶根据GTID自动选择适当的事务点进行复制,DBA基本上无需关注和担心主从不一致的问题,还是很让DBA省心的只
李
<李>
在启用<强> <强> 强,正常是不会发生GTID中间有个空隙,产生断点的问题发生。除非是下面这种情况:
李
<李>
1,人工暂停奴隶进程;
李 <李> 2、掌握上继续写入数据;
李 <李> 3、掌握上刷新日志;
李 <李> 4、掌握上删除旧BINLOG,只保留最新的BINLOG;
李 <李> 5,奴隶上启动主人,这时候会报错,像下面这样:
李 <李> Last_IO_Errno <强> 1236
李 <李> Last_IO_Error致命错误1236从主读数据时从二进制日志
李 <李> 李 <李> 针对这种问题的处理方法可以这么做: 李 <李> 1、关闭MASTER_AUTO_POSITION,即设置MASTER_AUTO_POSITION 0;
李 <李> 2,手工改变BINLOG文件,POS;
李 <李> 这种情况下,不能再次设置MASTER_AUTO_POSITION 1,否则还会再次报错只 李 <李>
李
<李>
<强>
李
-
<李>
1,正常配置复制复制,但是,也就是人工指定BINLOG文件,POS的传统方法;
李 <李> 2,在复制过程中,暂时关闭奴隶进程;
李 <李> 3、手工修改BINLOG文件,POS信息,指向新的BINLOG文件,POS点;
李 <李> 4,启动奴隶,这时候就会发现GTID断点的现象重现了;
李 <李> 在主从高可用模式下,可能主从间会发生切换,然后再次切换回来,这时候也可能发生上述的断点问题。因此我们建议采用双主来部署高可用切换,基本上可以实现任意来回切换,无需手工指定新的BINLOG FIEE,POS信息。 李 <李> 还有最后一种情况,就是在主人上执行了重置的主人,导致主人上的BINLOG文件,POS全部重置,奴隶上读取到的信息自然也就不一致了。 李 <李> 好了,说了那么多,我们最后来说下如何应对处理GTID断点的问题。
李 <李>
李 <李> <>强方法一:手工修改BINLOG文件,POS 李 <李> <强> 1,关闭奴隶;
李 <李> <强> 2,手工改变BINLOG文件,POS,指向主人上最新产生的BINLOG文件,POS,并且设置MASTER_AUTO_POSITION <强> 0;
李 <李> <强> 3,启动奴隶
李
-
<李>
<>强方法二:手工修改GTID_PURGED值
李
<李>
<强> 1,关闭奴隶;
李 <李> <强> 2,在奴隶上执行复位的主人,重设奴隶上的BINLOG文件,POS(如果这个节点用于复制中,继要注意所有binlog是否都被读取完毕,避免数据丢失),
李 <李> <强> 3,在奴隶上执行设置@@GLOBAL <强> GTID_PURGED
李 <李> <强> 4,启动奴隶;
李 <李> 这种做法比较费解一点,意思是,我们告诉奴隶要主动抛弃掉上大师传输过来的某些区间的事务。在这个例子中,我们抛弃了这12455个区间,也就是在GTID从2466年开始,又会继续应用继电器日志了,相比我们最开始的那个信息:
李
