故障公告再次出现数据库 CPU 居高不下的问题以及找到了最可能的原因

Posted cmt

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了故障公告再次出现数据库 CPU 居高不下的问题以及找到了最可能的原因相关的知识,希望对你有一定的参考价值。

非常非常抱歉,今天上午的故障又一次给大家带来麻烦了,再次恳请大家的谅解。

在昨天升级阿里云 RDS SQL Server 实例的配置后(详见昨天的博文),万万没有想到,今天上午更高配置的阿里云 RDS 实例依然出现了 CPU 居高不下的问题。

技术图片

在数据库 CPU 高的情况下,有时对访问速度影响不大,有时巨慢无边,在今天上午的故障期间,我们通过2次主备切换才恢复了正常。

下午,我们我们调整了服务器的部署,用了更多服务器进行混合部署(docker-compose与docker swarm),情况有了明显改善。

技术图片

但是,15:15 开始数据库 CPU 又飚了上去,但访问速度没有受到明显影响,一致坚持到 16:50 左右,在扛不住的时候,我们再次通过主备切换恢复了正常。

这次恢复正常后,我们才突然想到,数据库每天一大早会跑一个整理索引碎片的任务,是不是升级后这个任务不能正常执行了?打开 SSMS 一看,果然是。

昨天因为升级 SQL Server 后重建备库,整理索引碎片任务失败了。

Date		9/5/2019 06:30:00
Log		Job History (Reorganize Index)

Step ID		1
Server		SD39184A
Job Name	Reorganize Index
Step Name	Reorganize Index
Duration	00:00:00
Sql Severity	14
Sql Message ID	927

Message
Executed as user: xxx. Database ‘xxx‘ cannot be opened. It is in the middle of a restore. [SQLSTATE 42000] (Error 927).  The step failed.

今天不知什么原因整理索引碎片的任务也失败了。

Date		9/6/2019 06:30:00
Log		Job History (Reorganize Index)

Step ID		1
Server		SD39184A
Job Name	Reorganize Index
Step Name	Reorganize Index
Duration	00:00:00
Sql Severity	14
Sql Message ID	954

Message
Executed as user: xxx. The database "xxx" cannot be opened. It is acting as a mirror database. [SQLSTATE 42000] (Error 954).  The step failed.

CPU 高的问题很可能就是索引碎片没有被及时整理引起的,是否真的是这个原因,要等下周的访问高峰才能得到验证。

对于升级后整理索引碎片任务失败的问题,我们向阿里云提交工单后,阿里云建议我们先关闭 mirror database 。

alter database 库名 set partner off

目前我们没有采用这个建议,还在考虑更好的解决方法。

以上是关于故障公告再次出现数据库 CPU 居高不下的问题以及找到了最可能的原因的主要内容,如果未能解决你的问题,请参考以下文章

故障公告数据库服务器 CPU 近 100% 造成全站故障,雪上加霜难上加难的三月

故障公告攻击式巨量并发请求再次来袭,引发博客站点故障

故障公告取代 memcached 的 redis 出现问题造成网站故障

cpu故障导致丢包?

在 slideUp 动画结束之前再次触发函数时动画出现故障

故障公告突然猛增的巨量请求冲垮一共92核CPU的k8s集群