Mysql 异步复制延迟的原因及解决方案

在异步或半同步的复制结构中,从库出现延迟是一件十分正常的事。虽出现延迟正常,但是否需要关注,则一般是由业务来评估。
 

复制逻辑过程


1、主库将对数据库实例的变更记录到binlog中。 (此过程不会产生延迟)
2、主库会有binlog dump线程实时监测binlog的变更并将这些新的events推给从库(Master has sent all binlog to slave; waiting for more updates)(日志量越大,延迟越久)
3、从库的IO Thread接收这些events,并将其记录入relaylog。(日志量越大,网络传输时间越长,延迟越久)
4、从库的SQL Thread读取relaylog的events,并将这些events应用(或称为重放)到从库实例。(通常是造成延迟的主要过程)

 

如何判断延迟时长

在从库上执行SHOW SLAVE STATUS\G ;检查Seconds_Behind_Master值即可.

此方法的结果有一定的偏差,如果要求不是非常严格的话,使用是没有问题,要求严格的话,可以使用pt工具检查。

 

造成延迟的主要原因

MySQL的主从复制都是单线程的操作,主库对所有DDL和DML产生的日志写进binlog,由于binlog是顺序写,所以效率很高。Slave的SQL Thread线程将主库的DDL和DML操作事件在slave中重放。DML和DDL的IO操作是随即的,不是顺序的,成本高很多。另一方面,由于SQL Thread也是单线程的,当主库的并发较高时,产生的DML数量超过slave的SQL Thread所能处理的速度,或者当slave中有大型query语句产生了锁等待那么延时就产生了。(虽然5.7有并行复制功能,不过在大并发的情况下,从库并行度肯定会比主库低)

常见原因:Master负载过高、Slave负载过高、网络延迟、机器性能太低、MySQL配置不合理。

 

解决延迟的办法

1.升级数据库版本到5.7以上,开启并行复制,加大并行复制线程数到适合的个数

2.避免在主库上执行大的事务,将大事务拆分成小事务。

3.关闭从库binlog,修改innodb_flush_log_at_trx_commit配置。

4.确保每个表都是显示的递增主键,避免从库更新或删除时扫描全表。

5.根据从库上业务情况,可适当减小大表的索引个数,以减小每次操作时索引维护的开销。

6.如果业务允许,只复制部分库表数据。

7.减少从库上的操作,减小从库压力。

8.增加从库所在服务器的硬件配置。

9.优化网络,尽量内网复制

相关文章
相关标签/搜索