189 8069 5689
本文主要给大家介绍MySQL主从延迟问题应该如何解决，文章内容都是笔者用心摘选和编辑的，具有一定的针对性，对大家的参考意义还是比较大的，下面跟笔者一起了解下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. 避免让数据库进行各种大量运算，要记住数据库只是用来存储数据的，让应用端多分担些压力，或者可以通过缓存来完成。
看完以上关于MySQL主从延迟问题应该如何解决，很多读者朋友肯定多少有一定的了解，如需获取更多的行业知识信息 ，可以持续关注我们的行业资讯栏目的。
另外有需要云服务器可以了解下创新互联cdcxhl.cn，海内外云服务器15元起步，三天无理由+7*72小时售后在线，公司持有idc许可证，提供“云服务器、裸金属服务器、高防服务器、香港服务器、美国服务器、虚拟主机、免备案服务器”等云主机租用服务以及企业上云的综合解决方案，具有“安全稳定、简单易用、服务可用性高、性价比高”等特点与优势，专为企业上云打造定制，能够满足用户丰富、多元化的应用场景需求。