【TiDB 4.0 PCTA 学习笔记】- 3.9.4 Mutil Site Disaster Recovery @2班+马志林

课程名称:【TiDB 4.0 PCTA 学习笔记】- 3.9.4 Mutil Site Disaster Recovery (TiDB 跨数据中心部署方案)

学习时长:10m

课程收获:

了解如何在多副本的灾难故障恢复

课程内容:

一、造成数据丢失的几种情况
1、常见情况
a、某些region的全部副本在故障中丢失
b、某些region的大部分副本在故障中丢失,而剩余的副本又没有收到最近的写入

2、造成原因
a、sync-log 没有开启
b、TiKV的lable没有争取设置

二、数据恢复流程
1、恢复数据前


要记录重要信息:集群版本、sync-log参数配置、宕机的TiKV数量和日志 等
找到超过一半副本在故障节点的region,并记录ID

数据恢复思路主要是:
更改 raft group configure,使剩余成员具有选举条件;
对所有region都丢失的情况,需要空region,来解决region is unavailable错误,使其仍可正常提供服务。

2、数据恢复流程


调整PD配置,关闭集群调度


a、有两种方式,通过命令,找到超过一半副本在故障节点的region,记录id
b、在上升故障的节点上,把上述region设置为 tombstone状态,以取消TiKV启动时对上述故障的检查
tikv-ctl --db 使用的是本地模式,需要在TiKV shutdown前提下执行


在剩余正常节点上,移除上述region在故障节点的peer信息


至此,理论上仍然有副本健在的region,可以进行选举leader并提供服务
可以重启PD、重启TiKV集群、处理副本都丢失的region


再根据之前找到的region id ,创建空region,解决 region is unavailable错误
这样所有的region都可以提供服务。
后续使用API (curl http:// ),根据reigon id确认上述region属于那些表,对丢失数据进行处理


除了前述方法根据region id 找到丢失的表,
其实最有效的手段是 确定故障前几分钟 写入了哪些表,是否有ddl操作,是否可以重新消费更上游的数据重新写入。重导这部分数据,是最简单最完美的处理方式。否则只能对最重要的表和索引进行数据校验,保证集群的数据准确。
最后需要还原PD参数

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

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

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

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