tidb pctp 备战-m6米乐安卓版下载

计划外系统不可用原因

计划内系统不可用原因

用可提供服务的时间来评判

不可用时间=从故障发生到故障恢复所用时间

定义恢复时间目标(recovery time objective, rto)

指所能容忍的业务系统停止服务的最长时间，也就是灾难发生到业务系统恢复服务功能所需要的最短时间

定义恢复点目标(recovery point objective, rpo)

指业务系统所能容忍的数据丢失量，用时间表示，是指灾难发生到数据上一次备份的时间。

• leader选举:
  • 通过投票产生一个节点成为 leader
  • 检查宕机/网络隔离，选举新 leader
• log 复制︰
  • leader 负责接收客户端请求，在本地追加日志
  • leader 将日志复制给其他节点（并覆盖不一致的日志)
• 约束∶
  • leader 由超过一半节点投票选出
  • log 需复制给一半以上节点
  • 持有最新日志的节点才能被选为 leader

• 无状态∶
  • 数据由 tikv 存储
  • tidb 之间不通信（通过 tikv 和 pd )
  • 随时增加或删除
• 本身不支持 failover，需要业务配合

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

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

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

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

• 网络延迟
  • raft 协议要求写入复制到最少2个节点。(三副本)
  • leader 有可能与发起读取的 tidb server 不在一个区域。
  • 读取要访问 pd 获取一次tso，事务要获取2次。
• raft 协议本身
  • raft 协议要求写入复制到最少2个节点。(三副本)
  • 副本数最好为奇数。
  • 副本的分布最好与 tikv 节点的分布相结合。
• 其他
  • 多活要求。

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

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

• 使用 tidb binlog 或者 ticdc 组件进行异步复制
• 会丢失数据(rpo不为0)
• 有损恢复后，保证一致性
• 主集群或者从集群内部具有高可用功能