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

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

学习时长:8分钟

课程收获:学习并了解TiDB在灾难性的故障中如何恢复可用

课程内容:

数据丢失的几种情况

因为故障一些region的所有副本都丢失

因为故障一些region超过半数的副本丢失,存留的副本不能接收最近的写入

造成上述情况的原因,没有正确的配置sync-log参数和labels

恢复数据前需要做的操作

记录集群的版本,Sync-log的配置,异常的TiKV数量以及日志

找到在TiKV上失去超过半数以上的副本的Region

pd-ctl-u -d region --jq=".regions[]| {id:…id, peer_stores: [.peers[].store_id]l select(length as $total | map(if .==(1,4,5)then . else empty end)llength>=$total-length)}"

在有丢失数据的风险的情况下,询问是否可以容忍,情况具体如下:

A) 缺少最近写的部分

B) 一些地区的所有数据

C) 能否重定向一些丢失的数据

数据恢复步骤

为了在恢复过程中尽量减少可能的异常,我们建议对PDConfiguration进行调优,并暂时禁用相关的调度。

输入pd-ctl并执行以下命令:

config set region-schedule-limit 0

config set replica-schedule-limit 0

config set leader-schedule-limit 0

config set merge-schedule-limit 0

使用PD-CTL检查故障节点上超过一半副本的区域并记录其LDS

方法1.要求:对电力故障的TikV执行;TiKV关闭

$tikv-ctl --db /path/to/tikv-data/db bad-regions

方法2.要求:PD处于运行状态(假设故障节点为1,4,5)

$ pd-ctl-u -d region --jq=’.regions[]l {id:.id, peer_stores:[.peers[].store_id]| select(length as $total | map(if .==(1,4,5) then . else empty end) llength>=$total-length)}

将上面查询的区域设置为tombstone状态。

要求:在TiKV上执行故障点;TikV被关闭

$ tikv-ctl --db /path/to/tikv-data/db tombstone -r –force

在其余的正常节点上,故障节点上的对等点被移除–根据这些区域的数目,可以采用不同的解决方案:

4.1.如果您有少量这些region,那么失败节点上的所有对等点都可以是从给定区域的剩余副本中移除

$tikv-ctl --db /path/to/tikv-data/db unsafe-recover remove-fail-stores -s <s1,s2> -r <r1,r2,r3>

4.2.相反,位于失败节点上的所有对等点都可以从所有区域中删除,在所有不发生停电的情况下

tikv-ctl --db /path/to/tikv-data/db unsafe-recover remove-fail-stores -s <s1,s2> --all-regions

  1. 在这一点上,理论上,所有仍然有副本的区域都可以选举领导人,尽管我们已经分析过,他们可能会失去最近的一些更新。此时,我们可以重新启动PD,重新启动TiKV集群,并处理所有副本丢失的区域,如下所示:

使用pd-ctl检查不带LeaderRequirement:pd正在运行的区域

$ pd-ctl-u -d region --jq '.regions[][select(has(“leader”)[not)/{id:.id, peer_stores:[.peers[].store_id]}

  1. 创建一个空区域以解决不可用错误

$ tikv-ctl --db /path/to/tikv-data/db recreate-region --pd -r <region_id>

  1. 根据区域LD确认该区域所属的表或索引。

要求:PD,TiKV,TiDB正在运行

$ curl http://{TiDBIP}:10080/regions/regionlD}

  1. 在实践中,通常更有效的方法是直接询问用户在停电前的一段时间内写入了哪些表,是否有DDL操作,以及是否可以重新使用更多的上游数据来再次写入。

8.1.索引:检查数据索引的一致性

select count(*) from table

select count(*) from table force index 'idx_name`

8.2.For records: re-import this part of the data

  1. RESTORE PD调度参数

config set region-schedule-limit xx

config set replica-schedule-limit xx

config set leader-schedule-limit xx

config set merge-schedule-limit xx