最近一段时间内,无论在博客评论还是私信里,技术老铁们都对老张写的博客表示认可和支持,我很欣慰!从业多年就希望有一天能把自己学过的东西,遇到的问题,分享出来!我们大家一起进步!


今儿打算给大家分享的是如何解决MySQL主从延迟的问题,这个也是一些同学在生产中面临的比较棘手的问题,  经常给我打电话或者微信,说张老师,现在监控主从之间的延迟特别大。怎么办啊?!有什么办法可以避免延迟嘛?!

     

面对抛出这样的问题,我们先来了解下生产中有哪些主从架构?线上生产环境一般有一主一从,一主多从,多主一丛(级联复制,MySQL5.7之后才有) ,主主复制。主从架构存在目的就是为了故障切换和读写分离。它的原理如下图:


wKiom1mdNSTiE085AAFk3StgMB4526.png-wh_50


主服务器有一个工作线程 io dump thread

从服务器有两个工作线程,一个是io thread,一个sql thread。


主库把外界接收的SQL请求,记录到自己的binlog日志里面,从库的

io thread去请求主库 的binlog日志,并将得到的binlog日志写到自己的relay log(中继日志) 文件中;主库通过io dump thread,给从库 io thread 传binlog 日志。


大家可以看到在主库上事务的提交是并发模式的,而从库只有一个sql thread 工作,这种不公平的待遇,你说它能不延迟嘛。


剖析其重要的延迟原因在于:

1. 首先就是主库可以并发写入,从库只能通过单sql thread完成任务(MySQL5.7之前)

2. MySQL主从之间的同步,本来就不是时时同步的,是异步的同步,也就是说,主库提交事务之后,从库才再来执行一遍。

3. 在主库上对没有索引大表的列进行delete或者update的操作

4. 从库的硬件配置没有主库的好,经常忽略从库的重要性

5. 网络问题


解决方法如下:

1. 使用MySQL5.7版本,在5.7中引入了基于组提交的并行复制,设置参数slave_parallel_workers>0  和slave_parallel_type='LOGICAL_CLOCK'。

MySQL 5.7才可称为真正的并行复制,这其中最为主要的原因就是slave服务器的回放与主机是一致的。就是说主服务器上是怎么并行执行的,从库上就怎样进行并行回放。不再有MySQL5.6版本中库的并行复制限制。

2. 可以采用percona公司的percona-xtradb-cluster简称PXC架构,这种架构下可以实现多节点写入,达到时时同步。可参考老张的MySQL高可用架构三部曲之PXC。

链接地址:http://sumongodb.blog.51cto.com/4979448/1956086

3. 业务初期规划的时候,就要选择合适的分库、分表策略,避免单表,或者单库过大。带来额外的复制压力。从而带来主从延迟的问题。

4. 避免一些无用的IO消耗,可以上高转速的磁盘,SSD或者PCIE-SSD设备。

5. 阵列级别要选择RAID10,raid cache策略要使用WB坚决不要WT。

6. IO调度要选择deadline模式。

7. 适当调整buffer pool的大小

8. 避免让数据库进行各种大量运算,要记住数据库只是用来存储数据的,让应用端多分担些压力,或者可以通过缓存来完成。


目前能想到就这些,还望大家一起丰富解决办法。马上就要从夏季进入秋季了,在这个收获的季节,希望各位老铁,每天都能收获属于自己的那份技术带给你的快乐!