mysql 5.6 5.7 并存_mysql5.6,5.7 主从不同步解决办法

参考 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，如需转载请自行联系原作者