运维事故——数据库集群宕机事件复盘

爱可可的人生记录仪 2020-03-12

649

2020年3月3日6:30，像往常一样，我醒来会习惯性的翻一翻手机信息，与以往不同的是我看到微信的报警信息已经是三个点了，心里顿时凉了半截。点开一看，大量的应用服务报警，已经分不清到底是什么问题了，赶紧打开zabbix监控界面查看，红的瘆人的报警信息显得格外刺眼，世界终于安静了。

我们用的是一个定制的三主的数据库集群，由第三方专业的DBA管理。其实三台数据库都挂了，图没有截全。我赶紧群里喊话DBA，并打电话通知DBA处理，然后各个业务群都通告一遍，这次系统真的挂了。

我这边先把业务界面改成系统维护通告，数据库问题有DBA处理，我也不好插手添乱了。简单洗漱了一下，赶紧去公司打卡上班了，7点30左右，领导问话DBA进展情况，反馈说数据库不知道什么原因导致启不来。我们是没有备用的数据库的，当时选择三主架构也是看中了它的高可用性，没想到三台一起挂。这时不能再拖了，我们赶紧找了一台相同配置的测试机子（NEWDB01），把3号凌晨的完备数据拷过来进行还原，有453G的大小，一边进行还原，一边祈祷三主的数据库恢复(毕竟最理想的方法)。9点30，数据库还原好了，此时领导已经非常着急，催着我们赶紧上线使用，错过了最佳的数据恢复时机，完备时间点到故障发生点的将近5个小时的数据是没有的，当时我也没有意识到这个问题的严重性，实在欠缺考虑，导致了后面一大堆的问题和工作量。

我们都没有测试，直接改了ha的分发地址，开发重启服务连上直接跑了起来，从这一刻开始，虽然救急了，业务正常跑了，但少掉的那部分数据已经不能用binlog直接导入的最简单的方法来修复了。而且还有数据库版本不一致的隐患，毕竟定制的和直接开源的还是有一定的差距的。

下午，用户已经开始各种投诉，充值的钱怎么没有到账等等。领导各种讨论，最终打算把丢失的binlog解析成sql，靠人工核对账单有选择性的执行(最保险，但也是效率最差的)。忘提了，这个时候，三主的集群还是没有恢复，只是勉强启动了一台主机(RDB03)，据说是底层磁盘出现了问题，反正到现在第三方都没有定位出合理的故障。我本来想的是，把RDB03做个完备，然后恢复到另外一台机子NEWDB02上，再把今天的新机子NEWDB01的binlog导进去，这样就有一台数据齐全的NEWDB02主机，然后基于这台02做主备从的架构。但是，领导担心数据被覆盖毕竟前后环境不一样所以就放弃了，我也不坚定，因为确实也有道理，各位有好思路可以留下您的方法进行交流学习。

binlog的解析用了一款binlog2sql的工具，还是很不错的，推荐给大家。这部分缺失的sql大概花了两天时间才补上去，各种问题我也不想吐槽了。后面的主从没什么好说的，常规操作。

这次事故是我从业以来最严重的一次，希望不要再有下一次了，当然还有很多细节，就不一一赘述了。简单的总结反省一下吧：

备用主机一定要留几台，如果这次我们没有备用机，后果不堪设想。
做好备份，做好监控，老生常谈了。
中小公司能上云就上云吧，有一说一，大公司的云数据库产品不香吗？
出现问题，要冷静，按部就班特别涉及数据恢复的问题(反正已经宕机了三个多小时了，还在乎那么十几分钟的binlog数据恢复吗)，应变能力和决策能力也很重要。
一定要做好沟通和通告。
好好学习，增强实力，让问题扼杀在摇篮中。

PS：截止到现在第三方还没有具体的故障答复。。。从数据库的日志看貌似存储有问题，但系统日志没有异常，还是把时间交给第三方吧。

数据库

文章转载自爱可可的人生记录仪，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。

运维事故——数据库集群宕机事件复盘

评论

相关阅读