store offline异常

为提高效率,请提供以下信息,问题描述清晰能够更快得到解决:
【 TiDB 使用环境】
【概述】场景+问题概述
有两个tidb集群因为有机器故障需要下线tikv,执行scale in命令后等待大约3天左右发现还有极少region不能迁移。
初步分析,分别描述两个集群的问题
集群一

剩余一个region没有因为下线tikv而迁移,查询store的region信息和region的信息,这个region
有一个down peer,然后我主动remove peer,发现没有生效,去region的leader所在的tikv上查看日志,发现检索三天的日志都没有发现这个region的任何信息,其他副本所在的store的日志中也没有什么任何信息

集群二

  1. 另外一个集群(v4.0.14)下线tikv,发现剩余两个region无法完成下线

有问题的region信息如下:

对应region store以及store的region信息都进行过核对了,信息都是可以对齐的,不像https://asktug.com/t/topic/303575/28这里描述的哪些问题。
不知道如何处理

【背景】做过哪些操作
【现象】业务和数据库现象
【业务影响】
【TiDB 版本】
V4.0.14
【附件】

  1. TiUP Cluster Display 信息

  2. TiUP Cluster Edit Config 信息

  3. TiDB- Overview 监控

  • 对应模块日志(包含问题前后1小时日志)
1赞

没下线成功的region 可以根据region_id或者peer_id在 pd leader节点的日志看下 有没有啥调度失败的日志 以及tikv节点上 看到的相关报错信息也发出来下
或者看下tiup ctl pd -u http://pd_ip:pd_port -i
» operator show
看下正在调度的信息有没有这个region
顺便看下库里TIKV_REGION_PEERS和TIKV_REGION_STATUS表里 没下线成功的region_id的相关信息

幸苦把以上的相关信息收集下也发出来 方便大家排查 谢谢

集群一自己恢复了,下线完成,集群一的region信息算是正常,所以早上的时候手动remove down peer,下午刚刚成功了(发现remove一个peer,会看到N条相关的重复日志(Leader节点上),按照一定的间隔不断的打印,很久之后才会成功,不知道原因,好在可以成功)

emem 有时候会堵住 image 下线成功后这个是不是没了

这个是集群二中的,集群一中没有low space。集群二还在先找机器扩容一把看看

问题原因查到了,是因为这个要下线的tikv所在的磁盘故障了,这个tikv crash了,但是剩余的两个region还有副本在上面,region的信息就是上面截图中的。pending peer所在的store就是故障的tikv。目前已经没有磁盘空间不足的问题


强制设置这个tikv为Tombstone可以解决问题吗?目前看无法自我修复了

1赞

现在这个tikv节点还能拉起来吗 可以查下这个tikv节点上的 2个region 的三个副本对应的状态 如果其他两个副本正常 看看能不能move掉这个要下线的的kv的 peer 不行的话加 --force 强制下线吧

我按照tikv的日志,强制tombstone 有问题的region,现在tikv拉起来了,看看能不能搞定。
不过我觉得这里raft成员变更在5.0之前应该是有点儿问题,这个副本都已经pending半个月了,居然还在哪儿夯住。

正常可以move掉上面的region的副本 然后在别的tikv节点新增一个副本

operator show // 显示所有的 operators
operator show admin // 显示所有的 admin operators
operator show leader // 显示所有的 leader operators
operator show region // 显示所有的 Region operators
operator add add-peer 1 2 // 在 store 2 上新增 Region 1 的一个副本
operator add add-learner 1 2 // 在 store 2 上新增 Region 1 的一个 learner 副本
operator add remove-peer 1 2 // 移除 store 2 上的 Region 1 的一个副本
operator add transfer-leader 1 2 // 把 Region 1 的 leader 调度到 store 2
operator add transfer-region 1 2 3 4 // 把 Region 1 调度到 store 2,3,4
operator add transfer-peer 1 2 3 // 把 Region 1 在 store 2 上的副本调度到 store 3
operator add merge-region 1 2 // 将 Region 1 与 Region 2 合并
operator add split-region 1 --policy=approximate // 将 Region 1 对半拆分成两个 Region,基于粗略估计值
operator add split-region 1 --policy=scan // 将 Region 1 对半拆分成两个 Region,基于精确扫描值
operator remove 1 // 把 Region 1 的调度操作删掉
operator check 1 // 查看 Region 1 相关 operator 的状态

remove不掉了,leader选不出来了,所以才重启这个异常的tikv尝试恢复:joy:

解决了吗

没有,看来只能unsafe-recover remove-fail-stores 处理了
761 [2022/01/13 15:21:04.176 +08:00] [INFO] [store.rs:1451] [“tombstone peer receives a stale message, local_peer_id >= to_peer_id in msg”] [msg_type=MsgRequestPreVote ] [to_peer_id=308253312] [local_peer_id=308253312] [region_id=129434046]
762 [2022/01/13 15:21:04.880 +08:00] [INFO] [store.rs:1451] [“tombstone peer receives a stale message, local_peer_id >= to_peer_id in msg”] [msg_type=MsgRequestPreVote ] [to_peer_id=311204654] [local_peer_id=311204654] [region_id=104406]
有问题的store卡在这些日中中,重复这两个region的清理,但是看起来是卡主了,一直没有进展

昨天我这边下线了一个节点也遇到2个region 迁移不掉
pd的leader一直报这个错
[2022/01/13 15:42:30.085 +08:00] [INFO] [operator_controller.go:560] [“operator timeout”] [region-id=6656] [takes=10m2.268925854s] [operator="“replace-rule-offline-peer {mv peer: store [1498967] to [1660130]} (kind:region,replica, region:6656(327,475), createAt:2022-01-13 15:32:27.81616468 +0800 CST m=+1681107.672385966, startAt:2022-01-13 15:32:27.816276282 +0800 CST m=+1681107.672497577, currentStep:0, steps:[add learner peer 2072823 on store 1660130, promote learner peer 2072823 on store 1660130 to voter, remove peer on store 1498967]) timeout”"]
超时卡住 move 下线的那个节点的region也move不掉 这个下线操作感觉不太稳定

如果剩下的region 不多的话最好新建一个表把原来的数据迁移掉 然后删掉原表 把这个region变成空region先 免得操作有问题导致数据不可用unsafe-recover remove-fail-stores这一步要停所有的tikv我记得

集群规模太大了,只有两个region有异常,参考https://book.tidb.io/session3/chapter5/recover-quorum.html 感觉可以stop 对应的tikv,手动修复

/tikv-ctl --data-dir /data/deploy/tikv20171/db unsafe-recover remove-fail-stores -s 186631852,134 -r 129434046
[2022/01/13 20:02:54.150 +08:00] [INFO] [mod.rs:118] [“encryption: none of key dictionary and file dictionary are found.”]
[2022/01/13 20:02:54.150 +08:00] [INFO] [mod.rs:479] [“encryption is disabled.”]
[2022/01/13 20:02:54.155 +08:00] [WARN] thread ‘[config.rsmain:587’ panicked at ‘called Result::unwrap() on an Err value: Os { code: 2, kind: NotFound, message: “No such file or directory” }’, cmd/tikv-ctl/src/main.rs] [":121compaction guard is disabled due to region info provider not available"]
:57
[note: run with RUST_BACKTRACE=1 environment variable to display a backtrace
2022/01/13 20:02:54.155 +08:00] [WARN] [config.rs:682] [“compaction guard is disabled due to region info provider not available”]

这是什么问题??

现在的情况是以上两个有问题的region,根据他们所在tikv上get到的raft信息,store 134上没有这两个region,故障的store已经故障了,所以导致无法选举。
但是在OK的store上unsafe recover不成功,报错信息看起来跟rocksDB的一个参数有关

重启了那台下线中的tikv节点 调度正常了 region移动走了

这个tikv的数据是不是已经清除了?

unsafe recover恢复的