Mysql解决主从慢同步问题（上）

一.简介

一般主从复制，有三个线程参与，都是单线程：Binlog Dump（主） —–>IO Thread （从） —–> SQL Thread（从）。复制出现延迟一般出在两个地方

1）SQL线程忙不过来（可能需要应用数据量较大，可能和从库本身的一些操作有锁和资源的冲突；主库可以并发写，SQL线程不可以；一个大的sql语句导致执行很慢；）

2）网络抖动导致IO线程复制延迟（次要原因）。

SQL thread在执行IO thread dump下来的relay log的时间差。大家都知道relay log中event记录的时间戳是主库上的时间戳，而SQL thread的时间戳是从库上的，也就是说，如果主库和从库的时间是一致的，那么这个SBM代表的确实是从库延后主库的一个时间差。但是如果主库和从库的时间不是一致的，那么这个SBM的意义就基本不存在了。将主库时间调快1小时，那从库默认慢一小时。

为何有延迟

1.网络延迟 若主从之间网络延迟到，会造成sql线程无法实时将主的binlog日志复制过来。

2.机器性能差 若主用的固态硬盘，从用的机械硬盘，那读取速度自然不一样，会造成主写入很快，从在慢慢读取，这样就不适合读写分离了。

3.高负载 若从机器还安装了别的服务，用top可以看出是否有其它进程在占用资源，导致从性能下降。

4.磁盘负载 用iotop可以看到当前磁盘的负载，若正在复制某些东西，会导致将主的binlog复制过来了，但写入到从mysql中会很慢，数据不一致。

5.是否经常会有大事务？ 这个可能DBA们会遇到比较多，比如在RBR模式下，执行带有大量的Delete操作，或者在MBR模式下删除时添加了不确定语句（类似limit）或一个表的Alter操作等，都会导致延迟情况的发生。

这种可通过查看Processlist相关信息，以及使用mysqlbinlog查看binlog中的SQL就能快速进行确认。这个设想也被排除。

6.死锁 锁冲突问题也可能导致从机的SQL线程执行慢，比如从机上有一些select …. for update的SQL，或者使用了MyISAM引擎等。此类问题，可以通过抓去Processlist以及查看information_schema下面和锁以及事务相关的表来查看。

二.观察

在主上用SHOW MASTER STATUS;查看最新的binlog日志，在从上用show slave status\G;查看Master_Log_File，如果是一样的，说明sql线程将主的binlog日志都复制过来了，这是没延迟的。如果Seconds_Behind_Master是0则IO线程将同步过来的binlog日志都加载了，那延迟为0。

seconds_behind_master如果一直为0，突然就很高，那是因为主库在执行一个大的事件，当事件执行完成后从才开始复制，sbm会突然很高。