分布式数据库出问题了咋办，教你几招不慌张还能优雅搞定复杂故障

（引用来源：知乎专栏《老DBA的故障处理心法》）

分布式数据库出问题了,屏幕上跳红字，报警信息叮咚响，这时候你心里一咯噔，完蛋，怕什么来什么，别慌，你一慌，手下就容易乱，本来能快速搞定的小问题，可能真被你搞成大事故，处理故障，心态是第一道防线。

第一步,不是立马动手，而是先“止血”，想象一下，病人大出血，医生肯定是先压住伤口，而不是先研究病因，数据库也一样。（引用来源：阿里云数据库团队内部培训手册）如果问题已经影响到核心业务，比如用户完全无法下单或者页面疯狂报错，你的首要任务就是让业务先跑起来，这时候，别怕用“笨办法”，最经典的“止血”大招就是：重启大法或者切流。

重启某个看起来不正常的节点,或者把流量从出问题的数据库实例切换到备用的实例上，这听起来一点都不高大上，但关键时刻能救急，别觉得这招丢人，在各大厂的应急预案里，这永远是排在前几位的选项，先让业务恢复，再慢慢排查根因，这叫“止损优先”。

止住血了,业务报警消停了，你才能定定心心地当个“侦探”，开始第二步：找线索，分布式数据库的故障，很多时候表现得很“狡猾”，可能A服务报错，但根因却在遥远的Z组件上，不能只看表面的报错日志。

（引用来源：美团技术博客《一次漫长的分布式事务故障排查实录》）你要像个侦探一样，把所有线索串联起来，关键线索有这么几条：

1. 时间点：故障是几点几分几秒发生的？把这个时间点牢牢记住。
2. 错误日志：不仅仅是数据库的错误日志，还有应用服务的日志，看看在故障发生的时间点，前后到底打印了什么异常信息，是连接不上？是超时？还是报了什么具体的错？
3. 监控大盘：这是你的“天眼”，盯着整个链路的监控：CPU、内存、磁盘IO、网络流量，在故障时间点，哪个指标出现了毛刺（突然飙升或暴跌）？是某个数据库节点的CPU被打满了吗？是网络延迟突然飙升到几千毫秒了吗？监控图形会给你最直观的指引。
4. 变更记录：这是最容易忽略但往往是最关键的一步，赶紧去查一下，在故障发生前，有没有人做过什么操作？有没有上线新代码？有没有改动过数据库的配置？有没有做数据迁移或批量处理任务？十有八九，故障就是由某个变更引发的。

把这些线索像拼图一样拼在一起,你大概就能圈定一个怀疑范围了：哦，可能是新上线的那个功能把数据库拖慢了；或者是今天下午做的那个批量更新，锁住了全表，导致其他请求都卡住了。

线索收集得差不多了,就进入第三步：验证假设，你怀疑是网络问题，就尝试用工具测一下网络延迟和丢包率，你怀疑是某个SQL语句太慢，就去慢查询日志里把它揪出来，看看它的执行计划是不是出了问题。（引用来源：极客时间《分布式数据库实战》课程）这时候，你可能需要用到一些专业的命令或工具，但思路很简单：大胆假设，小心求证，通过简单的测试，复现问题，确认你的猜想。

原因找到了,解决起来就有针对性了，如果是慢SQL，就优化它或者加个索引，如果是某个节点硬件故障，就把它隔离下线，换上新机器，如果是新代码有Bug，赶紧回滚版本。

千万别忘了第四步：复盘，故障处理完，一切恢复正常，不是让你松口气喝杯奶茶就完事了。（引用来源：Google SRE运维模式）一定要组织复盘会，把这次故障的前因后果、处理过程、根本原因都写进文档里，最重要的是，要定下后续的改进措施：如何避免类似的代码再次上线？监控告警是不是可以做得更灵敏、更准确？应急预案是不是需要演练得更熟练？

你看,这一套流程下来，是不是就从容多了？总结一下就是：先止血，再破案，然后对症下药，最后总结经验，在复杂的分布式系统里，出故障是常态，不出故障才是意外，你能做的，就是练就一颗强大的心脏和一套清晰的排查思路，这样无论遇到多复杂的问题，都能优雅地搞定它，甚至还能从中学到新东西，让自己变得更厉害。