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

database

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

但是迁移迫在眉睫，我们不得不执行 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 配置已在启用前就做好了调优工作）：

此时 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 磁盘，服务恢复正常。

最后，此次事故的出现可以小结为：

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

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

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

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