Master 和 Slave 分别代表 MySQL 数据库，默认的情况下，客户端写入一个数据，Master 会把数据同步到 Slave 。在异常的场景下，当数据压力比较大的情况下，半同步退化成了异步的方式，我们看图左边的部分，这个时候写入一个数据 A ，但是返回给客户端成功之后，在同步给 Slave 之前，Master 节点 Crash 掉了，变的不可用了。

在右边的图里面，外面的监控系统发现了这个问题，把其中一个 Slave 提升成了 Master , 对外提供服务，这个时候我们想想会出现什么问题呢？在客户端读的时候，发现刚才写入的数据A 不见了，这个就是传统数据库复制方案里面很糟糕的事情，特别是如果写入的数据量很大，并且这些数据是核心数据，那就是一个非常严重的事故了。这种架构还有一个潜在的问题，看外部的监控系统，首先来说它也是一个单点，另外，他怎么能确认你的 Master 真正的挂掉了呢？我们知道网络是有三个状态的，atv，要么能 ping 通，要么 ping 不通，还一种情况就是超时。在这个复杂的网络条件下，你怎么能把 Slave 提升成 Master ，以及如果之前的 Master 又活了，你怎么能解决他和新的 Master 之间数据一致性问题等。

所以我们从这些角度来看的话，如果把这些操作全部交给运维人员来做，就会非常容易出现一些奇怪的问题。这也是我们之前在真实的业务、生产环境里面，遇到的一些实实在在的问题。基于此，那么新一代的数据库必须是可以自恢复的。如果把所有这些操作交给运维去做的话，其实很容易造成非常严重的影响。

顺着数据库发展的历史来看，终于到了 NewSQL 的这个时代。NewSQL 其实就是在传统的数据库基础上增加了扩容 Scale 的能力，而同时又保证之前的 ACID 事务和 SQL 支持。

到了 NewSQL 的时代，经过了一段时间的发展，工业界终于有了重大的突破，那就是 Google Spanner 和 Google F1 。它们的特性主要有几个方面：

① SQL 支持；②分布式 ACID 事务；③在线弹性伸缩能力；④自动的故障恢复；⑤跨洲际机房的数据安全。

从 Google 的 Spanner/F1 来看，结合刚才提到的问题，Google F1 提供了分布式数据库的基本上所需要的全部特性。当然最重要的是 Google 的 Spanner/F1 已经在 Google 的内部运行了一段非常长的时间。我们可以认为它是第一个在生产环境里面稳定运行的 NewSQL 数据库。

说起 Google，在云计算领域，基本上大家都是怀着朝圣的心态来看待的。整个 Hadoop 生态，都是建立在 Google 的GFS 、BigTable 和 MapReduce 三篇 paper 的基础上。在 Google 内部，经历了 BigTable —— Megstore —— Spanner/F1 的技术和架构演进，也就意味着， Spanner/F1 是 Google 当前最先进的数据存储技术的解决方案。大量的业务已经从原来的 BigTable 切换到 Spanner/F1 上，而且 Google 对外也高调地发布了Google Cloud Spanner 的基础云服务。我相信未来几年，就像当年的 Hadoop 一样，Spanner/F1 必然开启一个新的技术时代，包含着巨大的机会。目前，Google Spanner/F1 的开源实现主要有两个，一个是在美国纽约的 CockroachDB，一个就是我们的 TiDB。

TiDB 主要参考了 Google Spanner/F1 ，但严格来说又有些不同（图中标红的地方），最大的不同就在于 TiDB 是完整的兼容MySQL协议的。主要的原因是现在的市场上， MySQL 实在是太受欢迎了。所以大家都期望尽量在少改动业务代码的基础上可以用分布式数据库来解决数据库存储的问题。下面的一些特性，包括在线弹性扩展以及分布式的事务、在线的 DDL 和自动的故障处理，都是和 Spanner/F1 完全一样的；其他两点不同就是 TiDB 非常注重他周边 Ecosystem 的工具，以及 TiDB 一直在探索 Cloud 的方向，侧重点与 Google 也大有不同。

这是 TiDB 的整个架构：