【TiDB 4.0 PCTA 学习笔记】- 3.9.4 Mutil Site Disaster Recovery@1班:魔幻之翼

课程名称:课程版本(101/201/301)+ 3.9.4 Mutil Site Disaster Recovery

学习时长:

9 分钟

课程收获:

掌握tikv region异常的场景和导致的原因
掌握异常的场景下怎么使集群恢复正常

课程内容:

那些场景会导致数据丢失

  • 某些Region的全部副本在故障中丢失
  • 某些Region的大部分副本在故障中丢失,而剩余的副本又没有收到最近的写入数据

有哪些问题会导致上面的场景发生

  • sync-log 的参数没有正确的开启
  • lables 没做正确设定

建议记录一些重要的信息

  • 集群的版本
  • sync-log 的配置
  • 有多少tikv 出现问题
  • 需要找到有一半副本故障的region
    • pd-ctl -u -d region --jq = “.regions[]|{id:.id,peer_stores:[.peers[].store_id] | select (length as $total) | map (if.==(1,4,5,)) then . else empty and)|length>=$total - length)}”
  • 获取不能启动的tikv 的 日志信息

需要联系用户了解以下的场景

  • 少部分丢失的部分,最近没有写入数据
  • 大部分丢失所有数据的 regions
  • 需要获取到哪些部分的数据丢失

服务恢复的思路

  • 开启恢复操作
    • 为了将恢复过程中,异常情况的机率降到最低,建议调整PD 的配置信息,关闭集群的调度
      • config set region-schedule-limit 0
      • config set reglica-schedule-limit 0
      • config set leader-schedule-limit 0
      • config set merge-schedule-limt 0
  • 通过PD-CTL 找到发生一半故障的region的 唯一标识信息(ids)
    • 必须关闭 tikv
      • tikv-ctl --db /path/to/tikv-data/bd bad-regions
    • 必须调整PD 运行状态
      • pd-ctl -u -d region --jq = “.regions[]|{id:.id,peer_stores:[.peers[].store_id] | select (length as $total) | map (if.==(1,4,5,)) then . else empty and)|length>=$total - length)}”
  • 调整 region 查询放弃执行状态
    • 必须需要执行tikv shut down
      • tikv-ctl --db /path/to/tikv-data/bd tombstone -r --force
  • 剩余正常的节点移除这些故障的Region
    • 少量的regions 需要移除
      • tikv-ctl --db /path/to/tikv-data/bd unsafe-recover remove-fail-stores -s <s1,s2> -r <r1,r2,r3>
    • 全部的region 需要移除
      • tikv-ctl --db /path/to/tikv-data/bd unsafe-recover remove-fail-stores -s <s1,s2> -all-regions
  • 这些操作后,服务都能够正常的选举Learder,并且能够提供正常服务了,但是对于失效的Region仍然需要进一步的处理
    • PD 必须是运行状态
      • pd-ctl -u -d region --jq ‘.regions[]|select (has(“leader”))|not)|{id:.id,peer_stores:[.peers[].store_id]}’
  • 根据找到regions 的 id,创建空regions帮助解决无法达到错误
    • tikv-ctl --db /path/to/tikv-data/bd recreate-region --pd -r <region_id>
  • 基于Region id,配置region上的数据表和索引
    • 必须 PD,tikv,tidb 都是运行状态
      • curl http://{tidbip}:10080/regions/{regionID}
  • 实践中,最有效的手段,获取用户在出现故障前某个时间段内的操作,和写入了哪些相关表的数据,否则只能校验数据表中的数据和相关的索引
    • 索引恢复
      • select count(*) from table
      • select count(*) from table force index ‘idx_name’
    • 重新导入数据
  • 恢复PD 的调度参数
    • config set region-schedule-limit xx
    • config set reglica-schedule-limit xx
    • config set leader-schedule-limit xx
    • config set merge-schedule-limt xx

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

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

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

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