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 服务器作为主，所以数据一直保持着同步，这为迁移后快速回滚做好了准备。
对于此次变更给用户带来的不便，我们深表歉意。盲目自信和一时疏忽导致了这次事故，我们痛定思痛，坚决不让类似的事故再次出现。
因此我们要谨记：坚决不打没有准备的战！
越透明越可信，我们将这次过程完整分享出来，也更多的希望技术人可以多分享故障的过程以及处理的思路，避免更多的人踩坑。
