架构师必备：MySQL主从延迟解决办法

Posted 2021-10-17 Java烘焙师

上一篇文章介绍了MySQL主从同步的原理和应用，本文总结了mysql主从延迟的原因和解决办法。如果主从延迟过大，会影响到业务，应当采用合适的解决方案。

MySQL主从延迟的表现

先insert或update写入更新操作，再立即select查询，但是得不到最新的结果。
可通过show slave status命令，结果中的Seconds_Behind_Master列，查看主从延迟的秒数。

MySQL主从延迟的原因

1. 读写分离时，写操作走主库，读操作走从库，但是主库的变更还未同步至从库
2. 网络传输延迟：从库发起dump请求，主库推送binlog文件，从库写入本地relay log
3. 从库串行执行sql语句：主库并发的事务提交，但是在从库上只能串行执行，速度比主库慢

MySQL主从延迟解决办法

业务优化

如果业务场景允许，先写入更新操作，等待一小段时间后再查询。比如，新增一条记录，前端故意延迟半秒再调后端接口查询。

技术优化

• 拆库+并行复制：MySQL支持库级别的并行复制，拆库后每个分库的数据量变小，主从延迟自然也变小了。
• 慢sql优化除慢sql，也能降低主从延迟

终结方案

以上办法治标不治本，只能起到缓解主从延迟的作用，彻底根治还需这么做。

• 显式查主库：不同的分片中间件做法不一样，client侧分片可在每次查询前设置查主库的标记（ThreadLocal变量），proxy侧分片开启事务
  优点：实现简单，缺点：受MySQL QPS限制，QPS极高时不推荐
  

• 双写数据库和缓存，查缓存：避免MySQL主从延迟
  优点：可支撑高并发场景
  

MySQL主从同步延迟原因及解决办法

MySQL主从延迟原因以及解决方案：谈到MySQL数据库主从同步延迟原理，得从mysql的数据库主从复制原理说起，mysql的主从复制都是单线程的操作(mysql5.6版本之前)，主库对所有DDL和DML产生binlog，binlog是顺序写，所以效率很高。

slave的Slave_IO_Running线程会到主库取日志，效率会比较高，slave的Slave_SQL_Running线程将主库的DDL和DML操作都在slave实施。DML和DDL的IO操作是随机的，不是顺序的，因此成本会很高，还可能是slave上的其他查询产生lock争用，由于Slave_SQL_Running也是单线程的，所以一个DDL卡主了，需要执行10分钟，那么所有之后的DDL会等待这个DDL执行完才会继续执行，这就导致了延时。有朋友会说：“主库上那个相同的DDL也需要执行10分，为什么slave会延时？”，答案是master可以并发，Slave_SQL_Running线程却不可以。

2.MySQL数据库主从同步延迟是怎么产生的。

当主库的TPS并发较高时，产生的DDL数量超过slave一个sql线程所能承受的范围，那么延时就产生了，当然还有就是可能与slave的大型query语句产生了锁等待。

3.MySQL数据库主从同步延迟解决方案

（1）最简单的减少slave同步延时的方案就是在架构上做优化，尽量让主库的DDL快速执行。还有就是主库是写，对数据安全性较高，比如sync_binlog=1，innodb_flush_log_at_trx_commit=1 之类的设置，而slave则不需要这么高的数据安全，完全可以讲sync_binlog设置为0或者关闭binlog，innodb_flushlog也可以设置为0来提高sql的执行效率。

（2）另外就是使用比主库更好的硬件设备作为slave。

就是把，一台从服务器当度作为备份使用，而不提供查询，那边他的负载下来了，执行relay log里面的SQL效率自然就高了。

（3）增加从服务器喽，这个目的还是分散读的压力，从而降低服务器负载。

4.MySQL数据库主从同步延迟产生的因素。

1. 网络延迟 2. master负载 3. slave负载 一般的做法是，使用多台slave来分摊读请求，再从这些slave中取一台专用的服务器，只作为备份用，不进行其他任何操作，就能相对最大限度地达到’实时’的要求了

另外，再介绍2个可以减少延迟的参数 –slave-net-timeout=seconds 参数含义：当slave从主数据库读取log数据失败后，等待多久重新建立连接并获取数据 slave_net_timeout单位为秒 默认设置为 3600秒 slave_net_timeout 3600 –master-connect-retry=seconds 参数含义：当重新建立主从连接时，如果连接建立失败，间隔多久后重试。 master-connect-retry单位为秒 默认设置为 60秒 通常配置以上2个参数可以减少网络问题导致的主从数据同步延迟。

?

?

---------------------------------------------------------------------自己总结———————————————————————

主从同步延迟的解决办法：

(1)参数：我们知道因为主服务器要负责更新操作， 他对安全性的要求比从服务器高，所有有些设置可以修改，比如sync_binlog=1，innodb_flush_log_at_trx_commit=1 之类的设置，而slave则不需要这么高的数据安全，完全可以讲sync_binlog设置为0或者关闭binlog，innodb_flushlog， innodb_flush_log_at_trx_commit 也 可以设置为0来提高sql的执行效率 这个能很大程度上提高效率。

从库优化Mysql参数。比如增大innodb_buffer_pool_size，让更多操作在Mysql内存中完成，减少磁盘操作。

(2)版本：主从同步以后， 主服务器会把更新语句写入binlog, ? 从服务器的IO 线程(这里要注意， 5.6.3 之前的IO线程仅有一个，5.6.3之后的有多线程去读了，速度自然也就加快了)回去读取主服务器的binlog 并且写到从服务器的Relay log 里面，然后从服务器的 的SQL thread 会一个一个执行 relay log 里面的sql ， 进行数据恢复。

(2)硬件：使用比主库更好的硬件设备作为slave。

从库使用高性能主机。包括cpu强悍、内存加大。避免使用虚拟云主机，使用物理主机，这样提升了i/o方面性。

从库使用SSD磁盘。机械硬盘是靠磁头旋转到指定位置来读数据、写数据。转来转去的，我们叫做i/o。磁盘i/o存在速度瓶颈。固态硬盘是一个电子设备，电子设备不需要机械旋转，读写固态硬盘上任意位置的数据，速度都是一样的。

(3)网络：

网络优化。网络堵塞，也会导致同步延迟。跨机房的数据库同步，会存在同步延迟。保证主从在同一个机房里面去。

(4)代码：

业务代码的妥协。将实时性要求高的某些操作，使用主库做读操作。比如我写了数据到主库了，需要马上展示数据，不要到从库去读数据，因为从库可能还没同步过去呢。直接从主库读数据，保证是最新的数据展示。

?