189 8069 5689

MySQL慢日志优化的案例分析过程-创新互联

成都创新互联成都企业网站建设服务,提供网站设计制作、做网站网站开发,网站定制,建网站,网站搭建,网站设计,响应式网站设计,网页设计师打造企业风格网站,提供周到的售前咨询和贴心的售后服务。欢迎咨询做网站需要多少钱:13518219792

这期内容当中小编将会给大家带来有关MySQL慢日志优化的案例分析过程,文章内容丰富且以专业的角度为大家分析和叙述,阅读完这篇文章希望大家可以有所收获。

最近在分析一个问题的时候,尝试了很多的方法,算是一个逐步明朗的过程。

首先问题的现象是慢日志报警比较多,这是一套内部运维业务的数据库,涉及两个独立的数据库,我们暂且称为devopsdb(运维管理系统数据库),taskopsdb(任务管理数据库)。

现在报警的是taskopsdb这个数据库。

在开始之前,我先说下整体的环境和架构,数据库版本是5.7.25,使用了MGR架构模式,并且略微冒一些,使用了双活的模式,从业务上来说,devopsdb和taskopsdb数据写入上是独立的,所以直接的数据冲突可能性几乎没有。

devopdb的写入是实时的,业务种类比较多,而taskopsdb的写入相对要少很多,从我的直观关键,两者的压力基本是9:1或者差异更大。

有慢日志了就进行优化吧,但是这个慢日志报告让我有些懵,可以看到里面94%的响应时间是在处理commit的请求。

MySQL慢日志优化的案例分析过程

从慢日志的整体情况可以看到来自于两个客户端。

MySQL慢日志优化的案例分析过程

我们直接看下commit相关的SQL吧,结果打开一看慢日志文件,基本就是这样的输出结果,既然是慢日志,那么影响的数据行数应该是比较明显的,但是这里看到“Rows_examined”和“Rows_sent"都是0,但是很直白的是commit的执行时间依旧很长。

MySQL慢日志优化的案例分析过程

问题到了这里似乎有些两难,想优化但是苦于没有太直接有效的信息,在把整个慢日志梳理了一遍之后,我开始关注那5%的慢日志信息,发现确实有几个表的扫描代价太高了,算是一个优化点。

MySQL慢日志优化的案例分析过程

做完优化之后,发现报警频率确实少了很多,但是问题依旧存在。每次收到这样的报警信息,总是让人感觉到不舒服。

于是我开始想有没有其他的思路和方法。

我们从报警入手,报警的阈值是统计慢日志条数超过300就报警,所以我们可以入手的一个显式指标是300个慢日志,如何找到这300个慢查询,按照近期的报警信息,可以看到这些报警的时间相对是比较固定的,比如晚上22:00,或者早上9:00这样的时间,所以问题的发生存在周期性。

基于MGR的方案自身有一些特点,我们暂且先放下,嘉定我们不了解MGR.

两个节点的数据同步,基本是这样的场景,taskopsdb的短时间产生了大量的慢日志,而这些慢日志的表现是commit,这个commit的本质其实不是taskopsdb里面存在大量的commit操作,而是因为其他原因,导致原本无害的commit操作产生了堆积或者阻塞。所以commit的部分只是表象。

另外两个节点的数据同步,devopsdb的DML,DDL才会直接影响taskopsdb的负载,也就意味着devopsdb上面的慢日志从表面来看是不会影响taskopsdb的相关操作的。

顺着这个思路,我们往下分析,我下午的时候做了一个大胆的尝试,那就是从原来的MGR的模式降级为异步双主的模式,结果就好像潮水褪去一样,这些慢日志都付出水面了。

也就意味着根本的慢日志就是taskopsdb上面的两类不起眼的慢日志,修复了索引之后,这个问题就没有出现,当然这个问题的反思还在进行中。

上述就是小编为大家分享的MySQL慢日志优化的案例分析过程了,如果刚好有类似的疑惑,不妨参照上述分析进行理解。如果想知道更多相关知识,欢迎关注创新互联-成都网站建设公司行业资讯频道。


网站题目:MySQL慢日志优化的案例分析过程-创新互联
浏览路径:http://jkwzsj.com/article/iodjg.html

其他资讯