TiDB学习笔记（九）-数据库高可用设计-创新互联

TiDB Server的高可用

• 无状态
  • 数据由TiKV存储
  • TiDB之间不通信（通过TiKV和PD）
  • 随时增加或删除
• 本身不支持Failover，需业务配合

TiKV的高可用

• 故障恢复
  • 少数follower故障或隔离不影响Leader服务
  • Leader故障或隔离后，follower心跳超时会自动开始选举流程
  • 只有有一般以上节点存活，一定能选出新的Leader，从而恢复服务
• 数据一致性
  • 写入数据时，Leader会保证日志被复制到大多数节点
  • 当一部分节点故障或隔离后，只要有一半以上节点存活，其中至少有一个节点包含最新的日志
  • Raft协议选择包含最新日志的节点当做Leader
  • 综上所述，符合约束，则不会发生数据丢失

PD的高可用

• Leader节点提供所有服务，Follower为standby
• 依赖内嵌etcd实现leader选举
• 一致性要求
  • 分配严格单调递增的timestatmp
  • 同一时刻只能有一个leader

TiDB数据库的高可用

• TiDB数据库提供强一致性
• 如不能保证一致性，则拒绝服务
• 在PD和TiKV至少存活半数以上副本情况下，容忍一定限度内的节点宕机或隔离
• PD和TiKV可以自动故障转移至存活的大多数副本处
• TiDB server不保证所有节点同时提供服务
• 故障解决会伴随所有服务的降级

高可用架构设计中考虑的问题

• 网络延迟
  • raft协议要求写入复制到最少两个节点（三副本）
  • Leader有可能与发起读取的tidb server不在一个区域
  • 读取要访问PD获取一次TSO，事务要获取两次
• Raft协议本身
  • Raft协议要求写入复制到最少两个节点（三副本）
  • 副本数最好为奇数
  • 副本的分布最好与TiKV节点的分布相结合
• 其他
  • 多活要求

同城三中心架构

• 特点
  • 数据副本分布在三个数据中心或可用区
  • 同城网络延迟较小
  • 多活特性
  • RTO较小，RPO为0
• 问题
  • 写入与读取延迟高

同城两中心架构

两地三中心架构

• 特点
  • 可以保证任一数据中心失效后，服务可用不发生数据丢失
• 问题
  • 当两中心失效后，异地灾备不存在大多数副本，服务不可用
  • 异地灾备为异步复制，无法保证一致性恢复
  • 网络专心成本高

异步复制

• 使用TiDB binlog或者TiCDC组件进行异步复制
• 会丢失数据（RPO不为0）
• 有损恢复后，保证一致性
• 主机群或者从集群内部具有高可用功能

你是否还在寻找稳定的海外服务器提供商？创新互联www.cdcxhl.cn海外机房具备T级流量清洗系统配攻击溯源，准确流量调度确保服务器高可用性，企业级服务器适合批量采购，新人活动首月15元起，快前往官网查看详情吧