硬盘损坏重做kv节点报错

Still4 · 2020 年6 月 1 日 11:18

某个kv节点磁盘损坏，换了新磁盘，基本错误纠结在下面两个错误

20847616是原来的store，22290001是新的store

换了磁盘的kv上报错

[2020/06/01 06:38:06.120 +00:00] [ERROR] [transport.rs:137] [“resolve store address failed”] [err=“Other(”[src/server/resolve.rs:72]: store is tombstone [\“id](file:///%22id): 20847616 address: [\\\“10.121.93.145:20160\\\](file:///%2210.121.93.145:20160/)” state: Tombstone version: [\\\“4.0.0\\\](file:///%224.0.0/)” status_address: [\\\“10.121.93.145:20180\\\](file:///%2210.121.93.145:20180/)” git_hash: [\\\“198a2cea01734ce8f46d55a29708f123f9133944\\\](file:///%22198a2cea01734ce8f46d55a29708f123f9133944/)” start_timestamp: 1590741278 last_heartbeat: 1590897345796583001\”")"] [store_id=20847616]

[2020/06/01 06:56:21.246 +00:00] [ERROR] [util.rs:327] [“request failed”] [err=“Grpc(RpcFailure(RpcStatus { status: 2-UNKNOWN, details: Some(“invalid store ID 20847616, not found”) }))”]

[2020/06/01 09:36:33.687 +00:00] [WARN] [endpoint.rs:527] [error-response] [err=“Region error (will back off and retry) message: “to store id 20847616, mine 22290001” store_not_match { request_store_id: 20847616 actual_store_id: 22290001 }”]

尝试重启pd和db，结果pd正常，db重启失败

[2020/06/01 10:11:45.899 +00:00] [WARN] [backoff.go:304] [“pdRPC backoffer.maxSleep 40000ms is exceeded, errors:\ loadStore from PD failed, id: 20847616, err: rpc error: code = Unknown desc = invalid store ID 20847616, not found at 2020-06-01T10:11:41.311154285Z\ loadStore from PD failed, id: 20847616, err: rpc error: code = Unknown desc = invalid store ID 20847616, not found at 2020-06-01T10:11:44.034784863Z\ loadStore from PD failed, id: 20847616, err: rpc error: code = Unknown desc = invalid store ID 20847616, not found at 2020-06-01T10:11:45.899357952Z”]

神奇的是，在停掉新的kv节点大概一个小时候后，发现错误消失了，再把kv节点启起来数据已经正常进去了，之前的错误也没了，虽然集群现在稳定了，还是想知道是哪一步关键操作让集群恢复了

执行过的命令

pd-ctl store delete 20847616
curl -v -X DELETE http://10.155.111.136:2379/pd/api/v1/store/20847616?force=true
pd-ctl store remove-tombstone
./tikv-ctl --db /home/tidb/deploy/data unsafe-recover remove-fail-stores -s 20847616 --all-regions

另外想知道像这种磁盘损坏更换磁盘以后，重新部署的标准流程应该是什么样的

yilong · 2020 年6 月 1 日 11:40

可以参考【SOP 系列 08】线上集群扩缩容操作及要点按照先缩容，更换硬盘，扩容的方式操作。

Still4 · 2020 年6 月 2 日 03:27

按照缩容的说明

在缩容 TiKV 过程中，当缩容节点处于 Offline 状态时，千万不要停止 TiKV 进程，需要等待缩容节点状态变为 Tombstone 后才可以停止 TiKV 进程。

这个注意事项并不适合这次事故，因为磁盘损坏无法访问，设置offline以后节点状态一直是offline并不会更新，等了几个小时发现节点状态的leader为0，但是region跟其他节点一样，后面api调用强制下线，然后就出现to store id 20847616, mine 22290001的错误

来了老弟 · 2020 年6 月 2 日 04:05

你好，

可以反馈下完整的报错时间点 tikv 的日志，这边看下

反馈下 pd-ctl store 的信息，看下节点是否被完全下线，

在缩容流程中，如果故障节点已经下线，此时存在错误日志是正常的，通过扩容新 tikv 节点之后错误会慢慢消失

Still4 · 2020 年6 月 2 日 04:18

现在已经恢复了，之前的状态现在查不到了，日志基本都是主楼发的，每个节点都是重复错误

另外因为ip没有变，只是换了硬盘，刚部署完开始比较正常，大概半个小时后db连接数增长到1000，查询无响应，kv节点满屏幕都是这个错

[2020/06/01 06:38:06.120 +00:00] [ERROR] [transport.rs:137] [“resolve store address failed”] [err=“Other(”[src/server/resolve.rs:72]: store is tombstone [\“id](file:///%22id): 20847616 address: [\\\“10.121.93.145:20160\\\](file:///%2210.121.93.145:20160/)” state: Tombstone version: [\\\“4.0.0\\\](file:///%224.0.0/)” status_address: [\\\“10.121.93.145:20180\\\](file:///%2210.121.93.145:20180/)” git_hash: [\\\“198a2cea01734ce8f46d55a29708f123f9133944\\\](file:///%22198a2cea01734ce8f46d55a29708f123f9133944/)” start_timestamp: 1590741278 last_heartbeat: 1590897345796583001\”")"] [store_id=20847616]

[2020/06/01 09:36:33.687 +00:00] [WARN] [endpoint.rs:527] [error-response] [err=“Region error (will back off and retry) message: “to store id 20847616, mine 22290001” store_not_match { request_store_id: 20847616 actual_store_id: 22290001 }”]

最后似乎是执行了unsafe-recover remove-fail-stores又过了一个小时才正常

我就担心下次硬盘故障还会处理一整天没有标准化流程

Still4 · 2020 年6 月 2 日 04:23

pd-ctl store信息我记得比较清楚，故障节点在执行delete store_id以后一直是offline，因为硬盘挂了也不可能正常下线

yilong · 2020 年6 月 2 日 06:12

副本数是3 吗？ tikv 节点有3个以上吗？如果有多个tikv 节点，即使下线了一个节点，也不会丢失region，所以应该不需要使用 tilv-ctl 修复。重新扩容后会补充新副本。

Still4 · 2020 年6 月 2 日 06:40

kv节点是3个，leader在周日下午就已经自动迁移了，region倒是不担心丢失，就是周一缩容和扩容跟之前正常情况不太一样

缩容调用delete store id以后，节点的region size没有正常降低，于是用了强制下线api，看到变成tombstone以后，在原ip上扩容，启动起来看到日志中有大量store is tombstone错误，于是执行了remove tomb，然后就出现大量ip校验错误，集群压力变大无法访问

在之后做了很多操作，停掉扩容的kv节点，重启pd，重启db失败，挂了一个，剩余两个没动，报loadStore from PD failed, id: 20847616, err: rpc error: code = Unknown desc = invalid store ID 20847616, not found，重启kv，tikv-ctl修复，这一系列操作以后中间挂掉的db节点还是启动失败，接着查各种资料接近半个小时以后突然发现挂掉的db节点可以访问了，然后再把扩容的kv节点启动起来，发现就正常了

整个过程比较迷糊，不知道哪里是对的

yilong · 2020 年6 月 2 日 06:49

如果你缩容和扩容后的路径是一样的，缩容后，手工清理之前的遗留的数据，再扩容，是不是没有清理旧的数据信息？
修改为 tombstone 之后，先remove tombstone，再扩容吧

Still4 · 2020 年6 月 2 日 06:59

硬盘损坏没法清理旧节点数据，机房凌晨加班给换了硬盘

yilong · 2020 年6 月 2 日 07:04

换了硬盘就没问题了。下次你可以先把tombstone的在pd里清理干净，再扩容新的实例。应该就可以了。

Still4 · 2020 年6 月 2 日 08:30

好的，了解了

yilong · 2020 年6 月 2 日 10:11

anan · 2020 年8 月 17 日 03:47

你好，

画红线的目录是磁盘坏掉的那个节点吗

Still4 · 2020 年8 月 17 日 04:03

是的，我这里集群目录都是这个路径

yilong · 2020 年8 月 17 日 05:04

anan · 2020 年8 月 17 日 05:37

这个命令实在kv节点执行的还是在中控节点

我这个报错

Still4 · 2020 年8 月 17 日 06:20

所有kv节点依次执行的，如果想要kv节点下线的话参考rongyilong提供的文档吧，先缩容再扩容

anan · 2020 年8 月 17 日 06:31

意思是每个tikv姐点都执行这条命令吗？我现在情况跟你这一样，硬盘坏了只能把这个节点强制下线了，这个节点换了新盘，又重新扩容的。现在所有节点里频繁的输出日志都是关于坏掉这个节点的信息

Still4 · 2020 年8 月 17 日 06:50

对，每个kv节点都要执行这个命令，我理解是强制所有节点标记之前的store为下线

另外扩容之前有执行缩容吗，我印象中是执行了缩容，但是节点信息不更新，于是执行了强制下线；也可能是忘记执行缩容了，直接执行的扩容，才出现一系列错误。具体记不清了，不知道你的情况是什么