参考 http://blog.itpub.net/29510932/viewspace-1736132/
GTID_PURGE() 当同步发生大量的错误时,使用flush table with read lock锁住主库,记录GTID的事务编号(最后那个,
例如后面示例里面的142787),然后数据同步到从库,在参数中加上UUID(空格)起始事务编号(空格)中止事务编号原理:purge掉master log中,同步数据的SCN之前的事务,从同步时间点以后开始读取binlog; 这样做的好处是不用去master操作,清理binlog(手抖清理了其他东西就不好了~)
5.6
/usr/local/mysql/bin/mysqlbinlog --no-defaults -v --start-position="594374863" \
binlog.000283 > /XXX/binlog.sql
mysqlbinlog --base64-output=DECODE-ROWS -v --start-datetime="2017-05-02 20:00:00" --stop-datetime="2017-05-03 00:00:00" mysql-bin.001600> /home/back/test.sql
从以上输出中,我们可以知道,从夯住的那个点开始,binlog 记录的信息就出现了异常,可以推测在主库有大操作。另外,针对出现问题库,查看主库和从库的表数量,发现从库的表数量多于主库,有几个临时表出现。可以推测的,主库有删表的操作,从库同步夯住,导致同步异常,主库删表的操作还没来得及同步到从库。
经过和研发沟通,确认了两点。第一,确实有大操作,程序有大量的批量插入,而且是用的 LOAD DATA LOCAL INFILE;第二,主库确实有删表的操作,这几张表都是临时表
slave优化点
slave_parallel_worker
Master_Log_File: mysql-bin.003842
Read_Master_Log_Pos: 15198736
Relay_Master_Log_File: mysql-bin.003842
Exec_Master_Log_Pos: 15198736
Relay_Log_Space: 15199242
3.2017.12 数据迁移,做多源复制的时候,出现了问题
1236 error
解决办法
去2个主上,show GTID_PURGED
从好像是把两个主PURGED结合,然后SET @@GLOBAL.GTID_PURGED = 'b30dcce8-3395-11e6-902b-0050569d58f6:1-129112350';
再开启主从。
本文转自 liqius 51CTO博客,原文链接:http://blog.51cto.com/szgb17/1906790,如需转载请自行联系原作者