前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >MySQL延迟问题,无脑升级到8.0不是解决之道

MySQL延迟问题,无脑升级到8.0不是解决之道

作者头像
jeanron100
发布2020-04-15 17:27:01
4930
发布2020-04-15 17:27:01
举报
文章被收录于专栏:杨建荣的学习笔记

最近有一个数据库的延迟问题比较明显,大体的逻辑是有一批数据需要在缓存中校验,如果数据过期,就需要重新刷新数据,整个数据量大概有2000万,更新的数据量平均在600万左右,也就意味着基线变更数据是600万左右,需要根据数据的热度适时更新。

大体逻辑如下:

在缓存层面进行校验,查看数据的状态,

select xxxxx from test_list where uid=xxxx;

如果存在且失效,则进行更新:

update test_list set xxxx where uid=xxxx;

如果不存在则进行数据插入:

insert into test_list values(xxxx,xxxxx);

最早收到相关报警,是从高可用层面报出的,提示数据库产生了较大的延迟,导致高可用检测失败。查看历史的监控数据,发现在早间的一个时间段,比如9:00~10:00,会有明显的数据延迟情况。

其实可以做一下估算,每秒的QPS大概在2000左右(加上查询部分),产生的binlog是比较集中的。

可以补充一下对于延迟问题的分析,在高峰时段,没有任何慢日志,临时开启了general log,里面的逻辑也是比较清晰简单。在这种情况下想做优化,貌似空间不大,但是每天早上会收到高可用报警真是很烦。

于是为了能够快速收场,看MySQL 8.0在复制方面有了新特性writeset,为了并行对比已有的COMMIT_ORDER,WRITESET模式,我在这套环境的从库上面搭建了MySQL 8.0的Slave节点。

整个部署架构是类似这样的形式。

第二天静等数据结果,实际结果让我着实有些吃惊,开启了writeset之后,红色部分就是8.0的表现,相比绿色的部分MySQL 5.7差了很多。

当然这块可以对新版本的复制特性进行后续的讲解,调整为默认的设置之后,依然有差距。

这个问题的解决之道其实得跳开已有的背景和数据来看,而要从整个流程来切入,我从开发同学那里要来了相关的代码逻辑,也做了一些分析,下午的时候和开发同学进行了进一步的沟通,对于这个问题的处理结果还是颇有自信,期待明天的数据。

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2020-04-13,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 杨建荣的学习笔记 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
相关产品与服务
云数据库 SQL Server
腾讯云数据库 SQL Server (TencentDB for SQL Server)是业界最常用的商用数据库之一,对基于 Windows 架构的应用程序具有完美的支持。TencentDB for SQL Server 拥有微软正版授权,可持续为用户提供最新的功能,避免未授权使用软件的风险。具有即开即用、稳定可靠、安全运行、弹性扩缩等特点。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档