2020 年 3 月 5 日凌晨,码云主数据库切换问题记录
2020 年 3 月 5 日,农历二月十二,惊蛰,宜搬家、安机械。由于主数据库磁盘容量告急,我们决定将主数据库迁移至新的物理设备。上一次迁移是在 2018 年,我们从 SAS 磁盘迁移至 SSD 磁盘,当时对容量做了评估,但是国内开发者的热情和敬业精神十足,很快把我们的数据库磁盘塞满了。
因此我们决定再次迁移主数据库,这次我们准备了更大的磁盘,更好的设备。但是天有不测风云,新冠病毒疫情的扩散打乱了我们的计划,无限期延迟开工、交通管制等等因素导致我们的迁移计划不得不延后执行。
但是迁移迫在眉睫,我们不得不执行 plan B。
由于 SSD 设备无法就位,我们决定临时使用 SAS 设备作为新的数据库服务器。我们将服务器初始化、调优、部署应用、开始实时增量同步数据。
前期的准备工作有条不紊的进行着,看似风平浪静,然而一场悲剧正悄然酝酿。
2020 年 3 月 5 日凌晨 1:00 迁移工作进行到切换应用数据库连接地址这一步,此时我们需要对应用进行热重启,期间服务会有间歇性不可用,所以我们提前发出了公告。
我们确保数据一致后开始对后端应用配置的分发和热重启,事情进展顺利,数据库连接地址切换完成,应用正常,从库数据同步正常。
此时我们发现了一个问题,就是 MySQL slow_log
在不断增长,slow queries
是之前的 10 倍( 5-15/s ),此时并没有对线上服务造成影响,但此时是业务低峰期,并不代表明天业务回升也是如此。
由于新的数据库服务器使用的是 SAS 磁盘,相比此前的 SSD 磁盘性能有所下降,但在 SSD 之前我们也是使用但 SAS 磁盘,并且没有出现影响服务的情况。
从监控系统上看,新的数据库服务器表现为磁盘 io 耗时大, CPU iowait
高,于是我们做一些了简单的调整(服务器和 MySQL 配置已在启用前就做好了调优工作):
-
上调
innodb_buffer_pool_size
值,从24G
上调至48G
。 -
设置
sync_binlog
为0
,减少写入磁盘的操作。
此时 MySQL 和应用表现平稳,进展顺利,于是我们公布:迁移结束。
2020 年 3 月 5 日 上午 6:55 红薯在工作群里发了一张图,并吐槽道:“第一次加载很慢,第二次快”。一种不好的预感在运维组里扩散,要出事!
果然, 上午 7:25 ,此时的 slow queries
已经增长到 35/s
,尽管服务并没有表现出来很大的异常,但这绝对不正常!
随着访问量不断上涨,问题显现出来了。应用间歇性的出现 502
, slow queries
短时间上涨到 1k/s
以上。这时运维组已炸开了锅,登录服务器,联合 DBA 一起排查问题原因。
MySQL 服务器最直观的表现仍然是磁盘 io 耗时大, CPU iowait
高,此时 InnoDB Buffer Pool Data
已经上涨到 47G
,缓存写满了,缓存 / 物理内存占比 75%
,显然再上调缓存也无济于事。
问题就出在磁盘性能上。为了确保数据安全, MySQL 服务器磁盘阵列选择了 RAID10
,磁盘写性能相比 RAID5
低,同时磁盘为 SAS 磁盘,进一步降低了写性能,于是我们在 SSD 服务器上没有遇到的问题,在 SAS 服务器上遇到了。
在服务器上执行 iotop
时我们还发现 jbd2
这个进程占了 60% io 。 JBD( Journaling Block Device )日志记录块设备,为文系统日志记录提供了一个独立于文件系统的接口。可以通过以下命令查看分区是否开启:
sudo dumpe2fs /dev/xxx Filesystem features: has_journal
ext4
格式分区是默认开启的,而且不建议关闭。
最终,种种排查结果都指向了一点——磁盘性能。
到此,我们决定,将 MySQL 再次切换回 SSD 服务器,等采购新等 SSD 服务器就位后再次执行迁移。
于是我们决定回撤此次机器的升级。上午 10:10 分,我们抱歉的给用户发出了服务临时变更公告。
10:20 再次切换完成,应用数据库连接地址改回到 SSD 磁盘,服务恢复正常。
最后,此次事故的出现可以小结为:
-
时间紧急,设备未能及时就位,只能选择临时的应急预案;
-
对于 SAS 磁盘的性能我们想当然了,在最开始的 SAS 磁盘上运行正常的服务,随着业务量增加,性能需求上没有做好充分的评估;
-
对于新的 MySQL 服务器,我们在明知是 SAS 磁盘性能存在瓶颈的情况下,没有做好充分的性能测试,导致上线后性能不足以支撑服务;
所幸的是,原 SSD 磁盘在切换完成后就做了主从同步,将新 SAS 服务器作为主,所以数据一直保持着同步,这为迁移后快速回滚做好了准备。
对于此次变更给用户带来的不便,我们深表歉意。盲目自信和一时疏忽导致了这次事故,我们痛定思痛,坚决不让类似的事故再次出现。
因此我们要谨记:坚决不打没有准备的战!
越透明越可信,我们将这次过程完整分享出来,也更多的希望技术人可以多分享故障的过程以及处理的思路,避免更多的人踩坑。
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
快速上手百度大脑EasyDL专业版·物体检测模型(附代码)
作者:才能我浪费99 1. 简介: 1.1. 什么是EasyDL专业版 EasyDL专业版是EasyDL在2019年10月下旬全新推出的针对AI初学者或者AI专业工程师的企业用户及开发者推出的AI模型训练与服务平台,目前支持视觉及自然语言处理两大技术方向,内置百度海量数据训练的预训练模型,可灵活脚本调参,只需少量数据可达到优模型效果。 适用人群: 专业AI工程师且追求灵活、深度调参的企业或个人开发者 支持定制模型类型。 1.2. 支持视觉及自然语言处理两大技术方向: 视觉:支持图像分类及物体检测两类模型训练。 任务类型: 预置算法 图像分类: Resnet(50,101)、Se_Resnext(50,101)、Mobilenet Nasnet 物体检测: FasterRCNN、YoloV3、mobilenetSSD 自然语言处理:支持文本分类及短文本匹配两类模型训练,内置百度百亿级数据所训练出的预训练模型ENNIE. ERNIE(艾尼)是百度自研持续学习语义理解框架,该框架可持续学习海量数据中的知识。基于该框架的ERNIE2.0预训练模型,已累计学习10亿多知识,中英文效果全面领先,适...
- 下一篇
ActFramework 1.8.32 发布 - 高质量的 Java Web 应用框架
1. ActFramework 1.8.32 ActFramework 是一款高质量的 Java Web 应用框架. 最新的 1.8.32 版本带来了 20 项错误修复和更新. 其中值得关注的有: 1.1 通过 HTTP 访问 CLI 命令 #1305 熟悉 Act 的用户都知道在 Act 提供了大量的内置 CLI 命令, 也提供了非常方便的 CLI 命令创建机制. 如果需要在后端创建一个用户, 只需写出这样的代码即可: @PropertySpec("id") @Command(name = "user.create", help = "create user") public User create( @Required("specify user email") String email, @Required("specify user password") char[] password, @Optional("specify user role") Role role ) { User user = findByEmail...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- Jdk安装(Linux,MacOS,Windows),包含三大操作系统的最全安装
- 设置Eclipse缩进为4个空格,增强代码规范
- CentOS8安装Docker,最新的服务器搭配容器使用
- CentOS7编译安装Gcc9.2.0,解决mysql等软件编译问题
- CentOS8,CentOS7,CentOS6编译安装Redis5.0.7
- CentOS关闭SELinux安全模块
- Docker使用Oracle官方镜像安装(12C,18C,19C)
- SpringBoot2整合Redis,开启缓存,提高访问速度
- MySQL8.0.19开启GTID主从同步CentOS8
- SpringBoot2初体验,简单认识spring boot2并且搭建基础工程