MySQL主从延迟解决方案

Arce

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

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

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

　　

　　主服务器有一个工作线程 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. 避免让数据库进行各种大量运算，要记住数据库只是用来存储数据的，让应用端多分担些压力，或者可以通过缓存来完成。
　　

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