mysql5.7 主从不同步

erwewwewe

MySQL Binlog 【ROW】和【STATEMENT】选择
对比Row和Statement：R比S产生的日志量大5.5倍，网卡流量高4~5倍，cpu稍微忙了10个百分点。在复制过程中，从均没有延迟。因为SQL过滤条件WHERE 后面的字段利用好索引，ROW和STATEMENT模式下效果一样。要是没有利用好索引，则：
STATEMENT下：在主上执行（3~5s）一条，从上也是需要这个时间，并且出现延迟。（Seconds_Behind_Master）。本来就单线程的，导致从的可用性更差。
ROW下：在主上执行（3~5s）一条，正常情况下每张表都有主键，所以按照ROW的记录的SQL格式，不会出现对这类sql的延迟。除非极端情况下更新一张没有主键甚至没有任何索引的表。

对比发现：在执行此类sql的时候，在STATEMENT下面，（利用好索引）主和从的各个开销都很小，网络流量都不大。而在ROW下面：因为日志产生量就很大，导致在复制期间网卡流量就很大：12M。网卡流量：【1：10000】，日志大小：【1：2000000】，CPU空闲：【80：20】。这个只限于这个例子，看范围大小和表字段的大小。总之在网络和磁盘开销上面比较，他们差距了好几个数量级。
小结2：
    对于更新单条的sql语句，在STATEMENT和ROW下
1，CPU消耗差距不大，都需要执行这么sql。消耗 R=S
2，磁盘写和网络传输上，因为ROW记录的格式的原因。消耗 R>S
3，SQL效率来看，合理利用索引的更新，效率差距不大，不合理利用索引的更新，效率 R>S
4，日志文件大小上，因为都需要记录这么多SQL，但是由于R和S的记录格式不一样，大小 R>S
    对于执行一个大范围的sql语句，在STATEMENT和ROW下
1，CPU上，主上只要执行一条SQL，而从上需要执行N条，消耗 R>S
2，磁盘写和网络传输上，因为ROW记录的格式的原因。消耗R>S，看范围条件，大的话，差距巨大。
3，日志文件大小上，主记录一条，从记录N条，并且还由于R和S的记录格式不一样，R>S，差距巨大。
从上面的分析得出，STATEMENT要比ROW划算。要是使用STATEMENT没有任何问题的话，就推荐使用STATEMENT/MIXED格式记录二进制日志

http://www.cnblogs.com/zhoujinyi ... utm_medium=referral

mysql5.7 主从不同步GTID_NEXT
5.6的解决方案
http://suifu.blog.iyunv.com/9167728/1845457
end_log_pos 有了它，根据pos值，直接就能找到，找到delete那条数据，反做（变成insert）

原因
我在从库上操作了create语句，然后主从不同步了，所以解决办法就是跳过已经执行的sql

Last_SQL_Errno: 1050
Last_SQL_Error: Coordinator stopped because there were error(s) in the worker(s). The most recent failure being: Worker 0 failed executing transaction 'b30dcce8-3395-11e6-902b-0050569d58f6:38435158' at master log mysql-bin.001313, end_log_pos 19583512. See error log and/or performance_schema.replication_applier_status_by_worker table for more details about this failure or others, if any.

解决
1.master
mysqlbinlog mysql-bin.001313 (end_log_pos 19583512 对应#170314 19:28:02 server id 1  end_log_pos 19583512 CRC32 0xed572feb  Quer)

mysqlbinlog mysql-bin.001313|grep -C 10 "end_log_pos 19583512"

说明这行有问题
SET @@SESSION.GTID_NEXT= 'b30dcce8-3395-11e6-902b-0050569d58f6:38435158'/*!*/;
# at 19581673
#170314 19:28:02 server id 1  end_log_pos 19583512 CRC32 0xed572feb   Query   thread_id=23586111  exec_time=0 error_code=0

2.slave
stop slave;  
set @@session.gtid_next='b30dcce8-3395-11e6-902b-0050569d58f6:38435158';
begin;
commit;
set @@session.gtid_next=automatic;
start slave;

3.show slave status\G;
因为拖到早上解决，所以看下落后多少数据
Master_Log_File: mysql-bin.001319
Read_Master_Log_Pos: 2532411
Relay_Log_Pos: 27411621
Relay_Master_Log_File: mysql-bin.001313
Exec_Master_Log_Pos: 27411408
Retrieved_Gtid_Set: b30dcce8-3395-11e6-902b-0050569d58f6:38411883-38616860
Executed_Gtid_Set: 9b59f303-3433-11e6-8a48-0050569d2d94:1-146,
b30dcce8-3395-11e6-902b-0050569d58f6:1270-38443937

4.所以有必要利用pt工具强制同步

4.1
pt-table-checksum h='masterip',u='xx',p='xx',P=3306 --nocheck-replication-filters --replicate=test.checksums --no-check-binlog-format --ignore-databases=mysql --chunk-size-limit=5

4.2
pt-table-sync  --execute --replicate test.checksums  --sync-to-master h='slaveip',P=3306,u='xx',p='xx'

5.show slave status变化

[MySQL FAQ]系列 — MySQL复制中slave延迟监控
Read_Master_Log_Pos: 445167889
Exec_Master_Log_Pos: 445167889
Seconds_Behind_Master: 0

好了，最后我们说下如何正确判断SLAVE的延迟情况：
1、首先看 Relay_Master_Log_File 和 Master_Log_File 是否有差异；
2、如果Relay_Master_Log_File 和 Master_Log_File 是一样的话，再来看Exec_Master_Log_Pos 和 Read_Master_Log_Pos 的差异，对比SQL线程比IO线程慢了多少个binlog事件；
3、如果Relay_Master_Log_File 和 Master_Log_File 不一样，那说明延迟可能较大，需要从MASTER上取得binlog status，判断当前的binlog和MASTER上的差距；
在第三方监控节点上，对MASTER和SLAVE同时发起SHOW BINARY LOGS和SHOW SLAVE STATUS\G的请求，最后判断二者binlog的差异，以及 Exec_Master_Log_Pos 和 Read_Master_Log_Pos 的差异。

UserParameter=mysql.slave.Relay_Log_Pos
UserParameter=mysql.slave.Exec_Master_Log_Pos
UserParameter=mysql.slave.Read_Master_Log_Pos

监控项目
Read_Master_Log_Pos: 5374182
Relay_Log_Pos: 27113212
Exec_Master_Log_Pos: 27112999

Relay_Master_Log_File 和 Master_Log_File(需要增加)

1 2 3 4 5

mysql5.7 主从不同步 gtid_purged set global gtid_purged='xxxx' MySQL5.6 GTID新特性实践 MySQL5.7杀手级新特性：GTID原理与实战 GTID跳过SQL错误的脚本

GTID_PURGE() 当同步发生大量的错误时，使用flush table with read lock锁住主库，记录GTID的事务编号（最后那个，例如后面示例里面的142787），然后数据同步到从库，在参数中加上UUID(空格)起始事务编号(空格)中止事务编号
原理：purge掉master log中，同步数据的SCN之前的事务，从同步时间点以后开始读取binlog； 这样做的好处是不用去master操作，清理binlog（手抖清理了其他东西就不好了~）