MySQL三点告诉你，MySQL复制滞后怎么办

作者:课课家教育更新于： 2018-12-07 22:20:57

　　MySQL现在很火，不只是因为他有强大的体现，更重要的是他有强大的功能后台。MySQL复制被普遍认为是十分有效的，主服务器进行更改后，从服务器可在几秒内做出相应的改动。

     但如果发生两者之间同步缓慢的问题，那么主要有以下原因，我们今天来说一下。

　　1.从结点磁盘问题：复制操作对每个数据库都是由一个线程来完成，通常执行变更时的滞后是由磁盘延迟引起的。在这种情况下，您应该考虑使用c语言SSD加速这个过程。

　　2.带宽低/网络延迟高：如果两个服务器位于远程位置（高延迟的情况下）或c++11服务器之间的存在带宽较低的问题，我们应使用下面的方法之一或者两者结合使用，以最大限度地减少服务器间通信量。

　　3.使用基于语句的复制：基于行的复制会为数据库中每一行的变更创建一个SQL语句。基于语句的复制是应用程序发送的实际SQL语句的记录。通常基于语句的复制在记录大小方面更为有效。然而，你应该意识到，当你使用UPDATE...LIMIT1时，基于语句的复制可能并不十分有效

　　4.压缩通信量：MySQL支持使用slave_compressed_protocol参数进行日志压缩复制。这种方法将减少高达80%的服务器之间的通信。然而，压缩是计算密集型的，所以你应该意识到这样会产生一些额外的CPU利用率（这通常不属于数据库中的问题）。这个参数应该在两个服务器上都启用：

　　动态的从MySQL命令行输入：

     SET GLOBALslave_compressed_protocol = 1;

　　在MySQL配置文件中进行配置：

　　虽然mysqld进程的CPU消耗总是超过100%，不过也不算太高。再检查MySQL复制现场，确认了几个频繁更新的表都有主键，以及必要的c 11索引。相应的DML操作也几乎都是基于主键或唯一索引条件执行的，排除无主键、无合理索引方面的因素。

　　小编给大家举一个具体例子：

　　线上有个MySQL5.7版本的实例，从编程服务器延迟了3万多秒，而且延迟看起来好像还在加剧。

　　MySQL版本

　　看下延迟状况

　　我们看到，binlog文件落后了64个，相当的夸张。

　　MySQL5.7不是已经实现并行复制了吗，怎么还会延迟这么厉害?

　　先检查c语言系统负载。

　　看到mysqld进程其实负载还好，不算太高，也不存在严重的SWAP等问题。

　　再看I/O子系统负载，没看到这方面存在瓶颈(await\\svctm\\%util都不高)。

　　再看mysqld进程的CPU消耗。

　　虽然mysqld进程的CPU消耗总是超过100%，不过也不算太高。

　　再检查MySQL复制现场，确认了几个频繁更新的表都有主键，以及必要的程序设计索引。相应的DML操作也几乎都是基于主键或唯一索引条件执行的，排除无主键、无合理索引方面的因素。

　　最后只能祭出perftop神器了。

　　perftop-p`pidofmysqld`

　　看到perftop最后的报告是这样的

　　我们看到，bitmap_get_next_set这个函数调用占到了56.19%，非常高，其次是build_template_field函数，占了16.18%。

　　经过检查MySQL源码并请教MySQL内核开发专家，最后确认这两个函数跟启用表分区有关系。

　　查询下当前实例有多少个表分区：

　　竟然有3万多个表分区，难怪上面那两个函数调用那么高。

　　这个业务数据库几个大表采用每天一个分区方案，而且把直到当年年底所有分区也都给提前创建好了，所以才会有这么多。

　　不过，虽然有这么多表分区，在c语言master服务器上却不存在这个瓶颈，看起来是在主从复制以及大量表分区的综合因素下才有这个瓶颈，最终导致主从复制延迟越来越严重。

　　知道问题所在，解决起来就简单了。把到下个月底前用不到的表分区全部删除，之后约只剩下1.6万个分区。重启slave线程，问题解决，主从复制延迟很快就消失了。

　　小编结语：最起码，要理解你的复制行为为何滞后，然后了解如何使用正确的方法来解决滞后问题。是的，它就是这么容易，且十分有效。更多内容尽在课课家教育。