2020 年 3 月 5 日凌晨,码云主数据库切换问题记录

2020 年 3 月 5 日凌晨,码云主数据库切换问题记录

因此我们决定再次迁移主数据库,这次我们准备了更大的磁盘,更好的设备。但是天有不测风云,新冠病毒疫情的扩散打乱了我们的计划,无限期延迟开工、交通管制等等因素导致我们的迁移计划不得不延后执行。

但是迁移迫在眉睫,我们不得不执行 plan B。

由于 SSD 设备无法就位,我们决定临时使用 SAS 设备作为新的数据库服务器。我们将服务器初始化、调优、部署应用、开始实时增量同步数据。

前期的准备工作有条不紊的进行着,看似风平浪静,然而一场悲剧正悄然酝酿。

2020 年 3 月 5 日凌晨 1:00 迁移工作进行到切换应用数据库连接地址这一步,此时我们需要对应用进行热重启,期间服务会有间歇性不可用,所以我们提前发出了公告。

我们确保数据一致后开始对后端应用配置的分发和热重启,事情进展顺利,数据库连接地址切换完成,应用正常,从库数据同步正常。

系统监控各项指标很快就上来了。

旧 MySQL 服务器停用后,各项指标也降了下来。

此时我们发现了一个问题,就是 MySQL slow_log 在不断增长,slow queries 是之前的 10 倍( 5-15/s ),此时并没有对线上服务造成影响,但此时是业务低峰期,并不代表明天业务回升也是如此。

I/O 操作耗时对比,上为 SSD ,下为 SAS

由于新的数据库服务器使用的是 SAS 磁盘,相比此前的 SSD 磁盘性能有所下降,但在 SSD 之前我们也是使用但 SAS 磁盘,并且没有出现影响服务的情况。

从监控系统上看,新的数据库服务器表现为磁盘 io 耗时大, CPU iowait 高,于是我们做一些了简单的调整(服务器和 MySQL 配置已在启用前就做好了调优工作):

  1. 上调 innodb_buffer_pool_size 值,从 24G 上调至 48G

  2. 设置 sync_binlog0 ,减少写入磁盘的操作。

此时 MySQL 和应用表现平稳,进展顺利,于是我们公布:迁移结束。

2020 年 3 月 5 日 上午 6:55 红薯在工作群里发了一张图,并吐槽道:“第一次加载很慢,第二次快”。一种不好的预感在运维组里扩散,要出事!

果然, 上午 7:25 ,此时的 slow queries 已经增长到 35/s ,尽管服务并没有表现出来很大的异常,但这绝对不正常!

同时段, SSD 服务器 slow queries

随着访问量不断上涨,问题显现出来了。应用间歇性的出现 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 我们开始切换, 10:30 再次切换完成,应用数据库连接地址改回到 SSD 磁盘,服务恢复正常。

最后,此次事故的出现可以小结为:

  1. 时间紧急,设备未能及时就位,只能选择临时的应急预案;

  2. 对于 SAS 磁盘的性能我们想当然了,在最开始的 SAS 磁盘上运行正常的服务,随着业务量增加,性能需求上没有做好充分的评估;

  3. 对于新的 MySQL 服务器,我们在明知是 SAS 磁盘性能存在瓶颈的情况下,没有做好充分的性能测试,导致上线后性能不足以支撑服务;

所幸的是,原 SSD 磁盘在切换完成后就做了主从同步,将新 SAS 服务器作为主,所以数据一直保持着同步,这为迁移后快速回滚做好了准备。

对于此次变更给用户带来的不便,我们深表歉意。盲目自信和一时疏忽导致了这次事故,我们痛定思痛,坚决不让类似的事故再次出现。

因此我们要谨记:坚决不打没有准备的战!

越透明越可信,我们将这次过程完整分享出来,也更多的希望技术人可以多分享故障的过程以及处理的思路,避免更多的人踩坑。