iPhone 是如何丢失的

今天我可能把我的 iPhone 手机丢了。我原本以为这不可能发生，然而却发生了。它可能遗落在我办公室的桌上，或者是掉在公交车上。

假如它真的掉在公交车上，那就是从我的口袋里滑落出来的。

我有很多条裤子，其中一部分的口袋设计可能会让物品容易滑出，我选择穿这种裤子出门的几率约为 20%。即使是穿了这种裤子，手机也不一定会掉出，即便掉出也可能会被我即时发现。那为什么这次我却没发现呢？因为我坐的位置并非我平时的座位，那里的座位设计有可能让我在手机掉落时无法察觉，这种情况的概率大概有 10%。

我之所以没坐在常坐的位置，是因为今天下班晚了，车上人多，没法选座位。这也使得我需要转乘另一辆公交车才能回家，而我平时下车后会走路 1 公里回家，选择继续坐车(转车)的概率约为 10%。然而，我平时都会玩手机，下车时通常手机都在手上，理论上我不该丢手机。但事实上，我今天带了两台手机上班，所以有一台被我放在了口袋里。我这种手里拿着一台手机，口袋里还有另一台手机的发生概率非常低，大概只有 5% 以下。

那为什么我会带两台手机上班呢，就不能长期把备用机放在公司或家里呢？我是放在公司的，但在前段时间借了我的备用安卓手机给我的妻子，她也只借过我一次手机，用完还我了，所以我就把它放进书包带到公司了。这个概率极低，几乎不到 1%。那为什么我会在下班时把手机带回家呢？因为今天早上我忘记带 iPhone 的充电线了，只好用备用的安卓手机代替，我需要安卓手机用来刷公交卡回家。我忘记带 iPhone 的充电线的概率相对较高，约为 10%。

那我为什么不借同事的 iPhone 充电线呢？实际上，我的同事大多数使用的都是安卓手机，而坐在我前面的女同事恰好出差了，无法借她的充电线，这个概率很低只有 5%。我虽然可以继续寻找向坐得较远的不熟悉的同事借到 iPhone 充电线，但考虑到我手头还有备用的安卓手机和充电线，我就选择更换和使用安卓手机了。

以上的所有事件，都不是经常发生的，全是小概率事件，就是因为这些一连串小概率事件，经过计算以上事件连环发生的概率为 0.0000005%。而整个事情的源头居然是因为我忘记带充电线这件事。这不是一个好习惯，实际上，应该在公司长期放一根手机充电线，这样我也不用把手机充电线带来带去了。

不要小看小概率的小问题

同样地，我之前《高可用架构:为什么我不建议使用 MySQL 双主复制》这篇文章中表达了，我不建议使用 MySQL 双主复制架构，然而大家觉得问题很小，并且能规避，认为没问题，可以用。我只能说能不用则不用吧。

因为大家可以看到我前面丢失 iPhone 的例子，我从一个无关痛痒的坏习惯出发，经过一连串不同寻常的小概率事件，最终闯出大祸(几千大洋没了，照片等资料没了)。

回过头来，继续说我的这篇文章，文章的最后我举了个复制回环的场景例子。

例子中，数据写入 171 后，复制流转到了 172 ，之后流转写入到 173 后，一模一样的数据又回环回来，写回到 172 了。

MySQL 有自身的机制， server_id 可以防止事务的回环，但事务最开始的 server_id 是来自于 171 server 的，所以这个架构并没有防止回环成功，这样会有一个很小的痛点，就是复制的网络流量 double 了。好在 GTID 机制，可以避免数据重复写入，172 server relaylog 有来自 173 的数据，但未真正应用(被丢弃了)。(请详细阅读文章《高可用架构:为什么我不建议使用 MySQL 双主复制》)

有些人可能会觉得这个架构有些奇特，认为在现实环境中，这样的架构不会存在。但我想告诉你，这样的架构在在线实时迁移的过程中可能短暂存在过。又或者，你可以尝试不将 171 视为一个服务器，而是将其视为一个被 mysqlbinlog 等程序解析出带有 server_id 和 gtid 值的 SQL 文件。那么，如果我们将这个 SQL 文件直接导入到由 172-173 组成的双主架构上，这个回环问题会发生吗？

实际上，最近我们就遇到过回环问题，虽然具体的问题有些不同，更多是人为因素，但也可以归结为一系列的小概率错误事件导致的。

潜台词: 过于敏感不方便分享。

无论是回环还是脑裂，我都认为这些都是严重的事故。严重到什么程度呢？就是数据混乱了，你需要和业务部门确认每一条数据的最终正确状态，有时候甚至业务部门都无法确定，这就非常棘手了。简单地说，我只想避免这些问题的发生。我内心的想法是——这些事要么不发生，要么如果发生了，我就跑路。

我喜欢做脑洞实验，如果大家觉得以上的情况有我个人的想象成分，可以参考以下的国际案例。

这是来自加拿大的 MySQL 大牛 Jean-François Gagné 在 SREcon19 Europe/Middle East/Africa 大会上，分享的主题——Autopsy of a MySQL Automation Disaster

他在大会上分享了他在前东家 booking.com 经历的 MySQL 数据库脑裂故障的情况。他总结，这次脑裂的发生是由连续的 7 个错误步骤触发的。他表示，只要他们在这其中的任何一个步骤做得更好，或者没有出错，这次故障就不会发生。他承认在第五步，他犯了一个严重的人为错误。最后，他探讨了如何防止脑裂现象的发生，并分享了一些在脑裂发生后如何简化数据对账的策略。

在国内，无论参与哪种大会，大部分人都倾向于自吹自擂成功经验，很少人会分享他们的失败经验。其实，我很希望携程的专家们能在公开的大会上分享他们处理今年 329 机房故障的经验，因为我相信这可能也是一些小问题引发的雪球效应，从而演变成了大规模的故障。我并不赞同简单地开除负责人来了结这次事件。

最后

在数据库运维领域，常出现因连续发生的小概率事件而引发故障的情况。因此，一旦发现问题，应该查明其根本原因并进行纠正。不要轻视问题的重要性，否则当问题发生时，会有人看着你出丑，一边吃瓜子。