数据库与蝴蝶效应

蝴蝶效应的概念版本很多

我不知道怎么来解释，但是多年前看到过一个故事（段子）可以说明一下作为今天的铺垫。
下面的“我”是段子的主人公。
1某日，dota中，我看着对面的宙斯走来走去，心里极端不爽，终于心一横，一个锤子扔了上去，脑子又一热紧接着就冲了上去。队友全部冲锋上阵。结果他们宙斯死了，而我们4个全死了。看看时间，还有半小时我就要去上离散数学了，但是，我现在心里阴影颇深，因此，我脑子再一热，又开了一局…

2某时，离散数学课上，教授老头环视四周，发现教室内学生布局松散，老头望着下面，踌躇了一会儿，还是决定点名。这一点不要紧，90个人的班，有30+个没来。老头顿时怒了，虎躯一震喝到：现在电话通知没来的同学，半小时内赶不过来，期末成绩扣20分！

3某刻，一个女生在校门口等人，此时，一辆奥迪停在了她面前，车窗摇下，露出一个蜀黍温雅的笑容。女生也笑着准备上车，就在手触车门的时候电话响了，女生一边上车一边接起电话。刚听两句，女生面色一变：什么，那就是说如果我不去，期末得80分才能及格？！

4接完电话，女生很抱歉地告诉蜀黍，她有很重要的课，现在必须回去，要不今天就算了，改天再去吧。蜀黍绅士般地笑笑，点头同意，微笑着目送女生下车。然后，很用力的踩下油门，开车走了。

5某处，本来要去泰悦豪庭的车，无奈地停在这里。再启动的时候，车里多了一个MM。车里的两个人一直在聊天，他们的话题扯到了MM的BOSS。MM告诉蜀黍，他们BOSS一个车牌号就比蜀黍的奥迪贵，而且BOSS从来不把蜀黍这种级别的当回事儿，只有敏感敏感局委员以上的他们BOSS才待见。看着MM一脸自豪，蜀黍憋了许久的火气终于按捺不住，他觉得一个这样的人都敢藐视自己的存在。想到这儿，蜀黍顿时怒了，虎躯一震喝到：下车，你给我看着！

6某晚，多辆警车疾驰至天上人间等，数十名民警下车后冲进天上人间，出示证件后对各包房逐一检查。所有人被民警带到大堂集中接受调查，一时间大堂内挤满了穿着暴露的年轻女子，其中一女子低声念叨：他还真有这本事。

你看，我的骷髅王扔出一个锤子，天上人间就被查封了。 这就是蝴蝶效应。

段子铺垫完了，来说正事吧。

1由于按照规定需求下来的数据库设计（建表、字段和索引等数据库对象）应该得到审核被批准后才能进入开发环境，最终到正式环境。

2由于某个开发组的疏忽，有一个脚本中的若干DDL没有被审核过就去正式环境执行了。而这个脚本虽然在正式环境中的主从数据库上的得以执行，但是在OGG的这个环节上没有被抽取进程识别到。（写法有问题，如果经历过审核，是可以被识别的）。这样就导致了相关的OGG进程中断。

3运维人员看到这个中断，本着最快恢复的原则，立即进行重建。重建仅仅影响OGG的下游，对上游的交易没有影响。然而重建的过程有点长。

4本身这个重建对OGG会产生大量的IO，按理说不影响上游的交易。而在实际中有些上游的交易居然来读取下游的数据。也产生了大量的IO。这两个IO就发生了竞争。不仅重建的速度不快，而且也影响到了部分交易。

5之所以上游交易会到下游取数据是因为微服务和中台化让数据库过于分散，业务需要的数据需要跨库。而下游的数据才能满足这个要求。所以读取到了下游数据库。

6最终导致系统有一定程度的影响。

工作中这种类似的事情比比皆是

而数据库经常是蝴蝶效应的最初源头。所以控制好数据库，能控制不少问题。