store offline异常

KS贺大伟 · 2022 年1 月 10 日 06:10

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

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

集群二

另外一个集群（v4.0.14）下线tikv，发现剩余两个region无法完成下线

有问题的region信息如下：

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

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

相关日志和监控

TiUP Cluster Display 信息
TiUP Cluster Edit Config 信息
TiDB- Overview 监控

对应模块日志（包含问题前后1小时日志）

林先森cC · 2022 年1 月 10 日 06:34

没下线成功的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的相关信息

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

KS贺大伟 · 2022 年1 月 10 日 06:58

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

林先森cC · 2022 年1 月 10 日 07:12

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

KS贺大伟 · 2022 年1 月 10 日 07:15

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

KS贺大伟 · 2022 年1 月 11 日 03:11

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

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

林先森cC · 2022 年1 月 11 日 06:05

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

KS贺大伟 · 2022 年1 月 11 日 06:09

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

林先森cC · 2022 年1 月 11 日 06:14

正常可以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 的状态

KS贺大伟 · 2022 年1 月 11 日 06:45

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

林先森cC · 2022 年1 月 13 日 01:55

解决了吗

KS贺大伟 · 2022 年1 月 13 日 07:21

没有，看来只能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的清理，但是看起来是卡主了，一直没有进展

林先森cC · 2022 年1 月 13 日 07:45

昨天我这边下线了一个节点也遇到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不掉这个下线操作感觉不太稳定

林先森cC · 2022 年1 月 13 日 08:11

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

KS贺大伟 · 2022 年1 月 13 日 09:48

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

KS贺大伟 · 2022 年1 月 13 日 12:19

/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”]

这是什么问题？？

KS贺大伟 · 2022 年1 月 13 日 12:22

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

林先森cC · 2022 年1 月 14 日 01:57

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

林先森cC · 2022 年1 月 14 日 01:59

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

KS贺大伟 · 2022 年1 月 14 日 03:17

unsafe recover恢复的