MySQL 故障引发的思考--每人只错一点点

曾经在小学的时候看过一个故事。
具体内容，也就是到底当时每个人都做了什么，我记不太清了。依稀记得，那些船员做的都不是什么严重的事，甚至不能说做错了，但是结局却令人唏嘘。
故事，对我影响特别深重。
我从小长江边长大，小时候村里很多人扔垃圾都扔到江里，觉得流动的江水能带走垃圾，保持村子的干净。有次妈妈让我去江边扔垃圾，我犹豫了，她说：“大家都这样，靠你一个人世界就干净了？”当时的我妥协了，乖乖去了江边。
后来我才知道，就因为大家都这么想“我只是一点点”，所以不好才那样深，深到其他人再想挽救都无能为力。
故事我如今靠着百度，又找到了，可以看看：

每人只错一点点

巴西海顺远洋运输公司门前立着一块高5米宽2米的石头，上面密密麻麻地刻满葡萄牙文，记载了当年“环大西洋”号海轮沉船事故的原因。
当时事故发生后，巴西海顺远洋运输公司派出的救援船到达出事地点，但“环大西洋”号海轮消失了，21名船员不见了，海面上只有一个救生电台有节奏地发着求救的摩氏码。救援人员看着平静的大海发呆，谁也想不明白在这个海况极好的地方到底发生了什么，从而导致这条最先进的船沉没。这时有人发现电台下面绑着一个密封的瓶子，里面有一张纸条，上面这样写着：
一水理查德：3月21日，我在奥克兰港私自买了一个台灯，想给妻子写信时照明用。
二副瑟曼：我看见理查德拿着台灯回船，说了句这个台灯底座轻，船晃时别让它倒下来，但没有干涉。
三副帕蒂：3月21日下午船离港，我发现救生筏施放器有问题，就将救生筏绑在架子上。
二水戴维斯：离港检查时，发现水手区的闭门器损坏，用铁丝将门绑牢。
二管轮安特耳：我检查消防设施时，发现水手区的消防栓锈蚀，心想还有几天就到码头了，到时候再换。
船长麦凯姆：起航时，工作繁忙，没有看甲板部和轮机部的安全检查报告。
机匠丹尼尔：3月23日上午理查德和苏勒的房间消防探头连续报警，我和瓦尔特曼进去后，未发现火苗，判定探头误报警，拆掉交给惠特曼，要求换新的。
大管轮惠特曼：我说正忙着，等一会儿拿给你们。 服务生斯科尼：3月23日13点到理查德房间找他，他不在，坐了一会儿，随手开了他的台灯。
机电长科恩：3月23日14点我发现跳闸了，因为这是以前也出现过的现象，没多想，就将阀合上，没有查明原因。
三管轮马辛：感到空气不好，先打电话到厨房，证明没有问题后，又让机舱打开通风口。
管事戴思蒙：14点半，我召集所有不在岗位的人到厨房帮忙做饭，晚上会餐。
最后是船长麦凯姆写的话：19点半发现火灾时，理查德和苏勒的房间已经烧穿，一切糟糕透了，我们没有办法控制火情，而且火越来越大，直到整条船上都是火。我们每个人都犯了一点错误，但酿成了船毁人亡的大错。

今天之所以又想到这个事，是因为我的一个DBA 朋友，她所在环境发生的一起生产故障。
究其根本，其实也是这个原因。
早上她告诉我，她可能得引咎辞职了。我问她为什么，她说她造成一起严重的生产故障：

“我新搭建的主从，只是从库没有配置 read-only 。”

我听到这句话的时候，隐约是知道为什么。陆续沟通过程中，我才了解到就这么一个参数的“不存在”，造成了多么严重的损失。
也是沟通中慢慢了解到这个事故的发生，原来有那么多“同伙”，并且每个看起都不会造成那么大的影响，主要方面是以下几点：

1. 数据库主要参数配置及权限不够细致严谨。在我理解里，只是slave节点没有 read-only
   在这个事件里关系不是很严重。因为我个人习惯对权限控制比较重视。slave上的连接，用户该有的权限不多给。所以开发连接从库，不应该有修改数据的能力。
   可能很多环境中，大家也觉得这个不是很严重，由于mysql库是在主从同步的范围中的，主从用户权限等都是一样的。会从应用限制连接写实例，也就是应用配置的连接决定了是否实例有read-only的属性。
   因为一直以来工作的环境都是通过限制连接控制写入的节点的，可能我朋友想当然觉得主从是两个不同实例，一直的工作经验也没有这块的限制，都是在开发那边做好对应的连接配置了，只要他们正常使用，是不会有问题的。算未考虑到人的行为的不可控性，如果开发那边犯错，数据库就很危险了。

2. 运维监控配置有问题。他们公司各个服务器和应用也有部署监控。理论上她的主从实例配置存在问题，导致从库写入数据、主从同步失效就会有告警，但是刚好运维的监控配置有问题，没有及时报警。导致整个问题一直经过很久很久、开发同事查询数据才发现主从数据不一致，这才知道主从同步早就断开了。

3. 开发人员进行数据库实例连接配错误。开发人员也应该熟悉数据库基本架构、知道主从实例的情况。清楚明白各自负责的应用需求是什么，比如只是报表执行查询操作，或者连接前端、后端程序有数据交互、用户数据写入等。如果只是查询类需求，那么该应用配置里连接的该是slave；如果有写入需求，连接master。可刚好，他们的开发同事配置错误，有写入需求的某些应用被配置连到了slave上了，由于slave又未设置read-only参数，导致主实例和从实例都有数据写入成功。

最终的结果是：主/从节点都有相当量的写入，某大区数据仓数据混乱。

看似 dba只是没有配置 read-only。即使没有限制从实例不可写入，但只要开发连接没有错、运维监控无故障能及时发现及时止损，这个环境是健康的；
开发只是连接错实例，如果 dba 将 slave 的参数 read-only处理好了，或者用户权限控制合适了，就算连错了也无妨、运维有问题也不怕；
运维只是新增的主/从实例服务器的监控配置错误，如果 DBA 和开发人员都谨慎小心、正确完整操作，压根不需要告警，更别说需要背这个“数据仓数据混乱”的锅。

后来我问她，他们的操作是否只有单人确认、有没有经过 AB 角的检查核对。她告诉我没有。“其实我们这里 DBA 之间很少有沟通，除非想到一个事主动问。丢个脚本什么注释都没有，全靠猜。”。

关于这点我也是比较在意。飞哥说过“最好的沟通就是零沟通”，但是要达到这个，是需要大家有个共识，并且完成前期的沟通、知识储备。
否则每次处理一个事务都需要非常多的沟通。沟通太多容易有摩擦，更浪费时间成本，也考验共事者的耐心。所以，当某个人所掌握的模块有了变更，最好的做法是跟相关的人，AB 角色、有需求上游或者下游进行适当沟通，确保当需要对此模块进行操作的时候，大家比较快进入操作流程注意的共识。

往往成就你的，大多不是特别大“机遇”，好比彩票中了五百万。
往往毁掉现有成就的，也不一定是很大的“灾难”。
细节决定成败。