简介

TiDB实战篇-常用的高可用架构。

高可用要考虑的问题

同城三中心

RTO<35秒 RPO=0(因为一个数据中心挂点了，还有其他两个可以提供服务)

(优点)数据副本不能在同一个数据中心（raft多数存活）（PD的label标签能够解决这个问题）。

(缺点)每次写入的数据复制都要垮数据中心。

(缺点)读取数据时，可能用户连接的TiDB Server和要获取数据的Leader不在同一个数据中心，这时候就要垮数据中心读取数据，（因为默认只有Region的Leader才能够提供数据的读取服务）。

(缺点)在获取TSO的时候，如果作为Leader的PD和TiDB Server不在一个数据中心，那么也是有比较大的性能损耗。

优化

优化：所有的Region的Leader和PD的Leader都存储在一个数据中心中。

(优点)读取数据得到了优化，但是写数据的时候还是不能够缓解（多数派同意才能够写入成功）。

(缺点)TiDB Server形成单点，压力大。

同城两中心

架构

Regine的角色有voter(可以被选举中leader),follower(能够参与投票但是不能够成为leader),leaner(只是复制数据，不能够参与投票，也不能够成为leader) 。

效果如下

注意点

上面的架构，第一个数据中心按正常情况基本事务都会在数据中心一提交，如果数据中心一宕机了，数据中心二就会有数据的延迟，这里就有一个commit group（replication-mode = SYNC）的概念，可以设置有多少个voter成功了才提交。

怎么保证RPO为零

wait-store-timeout = 60s也就是上面commit group（replication-mode = SYNC）如果数据中心2挂了，因为配置了commit group（replication-mode = SYNC），那么这个时候因为要所有的voter执行成功才行，wait-store-timeout这个就是等待数据同步的超时时间。如果想继续服务可用，那么配置commit group（replication-mode = ASYNC）。如果数据中心二起来了以后那么设置commit group（replication-mode = SYNC）。如果数据中心的Leader挂了，那么还是能够保证RPO为零，因为设置commit group（replication-mode = SYNC)的效果是，可用的节点的数据都能够同步一致，数据才算提交成功。数据中心一挂一台，它还是能够保证数据中心一的新Leader和数据中心二的voter数据保证一致，那么就能够提交成功。

简单点说就是如果灾备中心出问题进入commit group（replication-mode = ASYNC）模式，当数据好了以后切入commit group（replication-mode = SYNC）的过程中，如果数据中心一的Leader挂了，灾备中心就会有数据落后。