【TiDB 4.0 PCTA 学习笔记】- 3.9.4 Mutil Site Disaster Recovery(TiDB 跨数据中心部署方案) @2班+李响

课程名称:3.9.4 Mutil Site Disaster Recovery(TiDB 跨数据中心部署方案)

学习时长:

15分钟

课程收获:

在多副本异常情况下,保障集群正常可用

课程内容:

一、Serveral situations in which data loss occurs

  1. 首先了解什么情况会出现丢失
  • 某些Region全部副本丢失
  • 某些Region大部分副本在故障中丢失,而剩余的副本未收到最近的写入
  1. 哪些场景容易触发上述情况出现
  • sync-log参数未开启
  • TiKV的lable没有正确的设置

二、Before you start data recovery

  1. 保持一些重要数据
  • 集群的版本、Sync-log的配置
  • 异常宕机的TiKV数量及日志等
  • 找到超过一半副本在故障节点中的Region,并记录他们的ID
    image
  1. 恢复思路
  • 更改raft-group-config,是剩余成员具有选举权
  • 对于所有region都丢失的情况,需要创建空Region解决Region Unavailable错误
    ,使其仍可正常提供服务

三、Data recovery steps(Region大部分副本丢失,但仍然有副本健在时)

  1. 为了在恢复过程中将异常情况降到最低,建议调整PD配置,关闭集群调度
    image
  2. 按照如下方式找到超过一半在故障节点上的region并记录ID
  3. 在发生故障的节点上把上述找到的region的状态设置为tombstone状态,去将TiKV节点启动时对这些Region检查
    image
  • 注意:使用tikv-ctl --db时,代表TiKV-CTL管理工具使用的是本地模式,此模式需要运行在TiKV节点shutdown模式下
  1. 在剩余正常节点上移除上述region在故障节点上的PRCC,视region数量我们提供了-r和–al两种模式简化操作
    image
  2. 截止到此,理论上仍有健在副本的region都可以正常选举出leader并提供服务,这时可以重启PD和TiKV集群处理无副本的region
  1. 根据上面找到的Region ID使用tikv-ctl创建空Region解决Unavailable错误
    image
  2. 根据Region ID确认Region属于哪个表或索引并处理
    image
  • PD、TiDB和TiKV需启动
  1. 在实践中,更有效的手段是询问用户在掉电前的某一段时间内,比如5分钟,大概写入了哪些表、是否有DDL操作、是否可以重新消费上游数据来再次写入,如果可以重导这部分数据,则是最简单最完美的恢复方式,否则只能对重要的表和索引进行数据校验,保证集群中存在的数据是准确无误的。
    image
  2. 恢复PD配置,开启集群调度
    image
  3. 完成以上恢复步骤后,所有TiKV是可以正常启动且数据库集群是没有报Region Unavailable错误

同学你好,感谢参与 TiDB 4.0 课程的学习!

本篇笔记逻辑清晰、内容丰富,被评选为优质笔记,将额外获得 20 积分,并在 「TiDB 培训」分类下获得“置顶”权益,积分兑换规则将于近期开放,敬请关注!

期待您继续产出优质内容!

此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。