第2章
两次失误的高度——预留从错误中恢复的空间

我想先和你分享一个我无意中听到的故事：

我们想知道—修改MySQL数据库上的一个设置会如何对性能产生影响，但是担心这个改动会导致生产数据库发生故障。因为我们不想弄垮生产数据库，所以决定将这个改动先应用到备份数据库上。毕竟，备份数据库并不是有人一直在使用。

听上去有点道理，是吧？不知道你之前有没有听到过这样的事情？

好吧，这里的问题在于数据库正在被人使用着。它目前的用途是为生产数据库提供备份，除此之外，它不应当被用于其他任何用途。

如你所见，出于实验性质的目的，备份数据库现在被用于测试不同的设置。这样带来的结果就是，随着这些设置生效，备份数据库与主生产数据库的差异开始越来越大。

直到，有一天，不可避免的事情发生了。

生产数据库出现了故障。

备份数据库一开始的确做了应该做的事—它接管了主数据库的工作，只是事实上它做不到。由于备份数据库上的设置已经与主数据库上的设置相差太多，导致它无法再正常处理原来主数据库上的数据。

于是备份数据库慢慢发生了故障，然后整个网站都无法工作了。

这是一个真实的故事。你有一个备份、复制的数据库，原本准备是在主数据库发生故障时，作为主数据库来使用的。但是，这个备份数据库没有受到像主数据库一样的尊重对待，并且也失去了它的主要能力—成为备份数据库的能力。

两次失误不会让事情变得正确，两次失误也无法抵消彼此，两次失误也无法自己修复。一次主数据库故障再加上一个管理不善的备份服务器，会让这一天变得糟糕。我们如何能避免这类可靠性问题呢？无线电控制飞机会告诉我们答案。