今天发现在153服务器insert一条数据，然后查看从库154和162都没有这条数据，但是在154和162执行show slave status 显示的双yes 后来重启了153 154 162的mysql还是有这个问题。等了大概20分钟
154 和162才同步完成数据。后续需要继续排查问题所在。https://www.cnblogs.com/gaoyuechen/p/8628036.html
当时查看了seconds_behind_master 大概都在2000-5000的样子
2019-09-19更新
今天发现154和162的seconds_behind_master都在20000多，这两台都是153的从库，难道是153的读写事务太多？
后来网上看了这个文章 https://blog.csdn.net/weixin_34049948/article/details/89821388
先查看进入154服务器的docker 安装的mysql服务端 执行 mysql -u root -p
然后 show slave statusG 主要查看 Relay_Master_Log_File: mysql-bin.000616 和 Exec_Master_Log_Pos: 59270494
Relay_Master_Log_File: mysql-bin.000616
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 59270494
如果发现长时间这两项不变就可以是153主库有什么比较大的事务在执行导致154从库同步很慢
然后在153主库通过
mysqlbinlog -v --base64-output=decode-rows --start-position=586749146 mysql-bin.000615 | more
看到了obs_issue_info_30 这个表有大量的delete操作，后来询问了大数据同事，他那边每3个小时有大量的delete和insert操作往153写入。所以问题找到了153被大数据平台大量写入导致154和162同步延时很大。而作为主主的另外一台154没有大数据写入，所以153作为从库同步154的数据很快，seconds_behind_master是0
接下来让大数据同事把写入减少时间间隔再观察一下是不是154和162的seconds_behind_master降下来了。
后面附上文章中说的排查mysql主从同步延时的排查方法
https://yq.aliyun.com/articles/505185
主从延时如果排查？
1. show slave statusG，看一下relay_master_log_file & exec_master_log_pos数值有没有变化（如果是GTID复制也可以看executed_gtid_set的事物号有没有增长 ），如果一直不变化，说明有大事物，导致sql_thread线程hang住，这个时候需要查看主库的binlog，看一下是什么事物：
mysqlbinlog -v --base64-output=decode-rows --start-position= exec_master_log_pos relay_master_log_file | less
然后等大事物结束或者回滚；
这次事物结束后，如果下次从库不能接受这样延时，怎么办，有什么根本的解决方法？
（1）把从库对读要求比较高的业务切换到主库上；
（2）以后更新大事物拆分成多个小事物，比如说一次更新20万条改为一次更新10万条；
2. 如果relay_master_log_file & exec_master_log_pos数值增长很慢，怎么办？
（1）解析对应的binlog： mysqlbinlog -v --base64-output=decode-rows --start-position= exec_master_log_pos relay_master_log_file | less
查看对应的表，看看表有没有主键，索引等结构
（2）检查系统是不是过载cpu,memory,io，
io可以通过工具iotop和pt-ioprofile查看
如果发现是mysql库下的slave_relay_log_info.ibd文件占用IO很高，可以考虑调大sync_relay_log_info，让这个文件同步不要太频繁。
cpu可以通过top命令查看:
如果user比较高，可以show processlist查看，慢日志，有没有大量的排序，主要是sql语句
如果sys很高的话，一般来说，因为：
1、发生swap
2、数据库内发生严重的锁等待
3、用了ssd等设备，产生大量中断，或者网卡中断（cpu中断不均衡）
4、MySQL里频繁创建连接及关闭
5、频繁用到timestamp列，且time_zone=SYSTEM
memory：
free -gt
vmstat
看看mysql的errorlog，主从的server-id是否不一样
如何查看网卡是否连接：
ifconfig |grep up
dmesg|grep eth
以上方法都不行的话，可以尝试其他方法：
使用工具perf top
pstack `pidof mysqld`
ipmitool
硬件方面raid卡等