lmy012
(Lmy012)
2020 年8 月 11 日 07:53
1
为提高效率,提问时请提供以下信息,问题描述清晰可优先响应。
【TiDB 版本】:V4.0.0
【问题描述】:
今天集群其中一个tikv节点异常后,一直在自动尝试重启,开始的报错如下,请帮忙看看需要如何启动这个节点,谢谢。
集群架构中有10来个tikv节点
tikv.log.2020-08-11-14:53:05.186921362:[2020/08/11 14:28:05.824 +08:00] [ERROR] [status_server.rs:577] [“failed to register addr to pd”] [response=“Response { url: “http://10.71.80.134:2379/pd/api/v1/component ”, status: 400, headers: {“access-control-allow-headers”: “accept, content-type, authorization”, “access-control-allow-methods”: “POST, GET, OPTIONS, PUT, DELETE”, “access-control-allow-origin”: “", “content-type”: “application/json; charset=UTF-8”, “date”: “Tue, 11 Aug 2020 06:28:05 GMT”, “content-length”: “72”} }"]
tikv.log.2020-08-11-14:53:05.186921362:[2020/08/11 14:28:05.824 +08:00] [ERROR] [status_server.rs:577] [“failed to register addr to pd”] [response="Response { url: “http://10.71.80.134:2379/pd/api/v1/component ”, status: 400, headers: {“access-control-allow-headers”: “accept, content-type, authorization”, “access-control-allow-methods”: “POST, GET, OPTIONS, PUT, DELETE”, “access-control-allow-origin”: " ”, “content-type”: “application/json; charset=UTF-8”, “date”: “Tue, 11 Aug 2020 06:28:05 GMT”, “content-length”: “72”} }”]
lmy012
(Lmy012)
2020 年8 月 11 日 09:40
3
1、用tiup部署的,之前一台tikv是down的状态,现在被我缩容了,所以现在的状态是Pending Offline
2、日志看看这个,后续集群重连一直没看到有ERROR的信息
tikv_log.gz (1.9 MB)
lmy012
(Lmy012)
2020 年8 月 26 日 01:58
5
rongyilong-PingCAP:
查看报错为 [2020/08/11 14:27:44.900 +08:00] [FATAL] [lib.rs:481] [“rocksdb background error. db: raft, reason: flush, error: IO error: While appending to file: /data/tidb-data/tikv-20160/raft/068444.sst: Cannot allocate memory”]
您好,之前由于这个问题,整个生产库铲了后重建库了。今天,我在测试环境搭建了一套tidb,现在重现了这个问题。目前情况如下,
直接在/data/tidb-data/tikv-20160/db 目录下把060105.sst 文件挪到其他目录,然后kill掉tikv,之后查看store中,80主机状态异常
store --jq=".stores[].store | { id, address, state_name}"
{“id”:124,“address”:“10.71.1.73:20160”,“state_name”:“Up”}
{“id”:1,“address”:“10.71.1.81:20160”,“state_name”:“Up”}
{“id”:4,“address”:“10.71.1.87:20160”,“state_name”:“Up”}
{“id”:5,“address”:“10.71.1.83:20160”,“state_name”:“Up”}
{“id”:6,“address”:“10.71.1.80:20160”,“state_name”:“Disconnected”}
日志:
[2020/08/26 08:59:51.075 +08:00] [FATAL] [server.rs:357] [“failed to create kv engine: RocksDb Corruption: Can’t access /060105.sst: IO error: No such file or directorywhile stat a file for size: /data/tidb-data/tikv-20160/db/060105.sst: No such file or directory\
”]
对于这种情况,是否能通过数据修复的方法来恢复这个节点?
lmy012
(Lmy012)
2020 年8 月 26 日 07:03
7
我也看了很多tikv节点异常的处理方法,按照他们的方法,却没有重启节点
比如在所有正常的4个tikv节点 强制region从多副本失败状态恢复服务
[hdbuser@bigdata-prd-dn-04 scripts]$ /tmp/tikv-ctl --db /data/tidb-data/tikv-20160/db unsafe-recover remove-fail-stores -s 6 --all-regions
removing stores [6] from configurations…
success
[hdbuser@bigdata-prd-zk-01 ~]$ /tmp/tikv-ctl --db /data/tidb-data/tikv-20160/db unsafe-recover remove-fail-stores -s 6 --all-regions
removing stores [6] from configurations…
success
[hdbuser@bigdata-prd-dn-10 tmp]$ /tmp/tikv-ctl --db /data/tidb-data/tikv-20160/db unsafe-recover remove-fail-stores -s 6 --all-regions
removing stores [6] from configurations…
success
[hdbuser@bigdata-prd-dn-06 ~]$ /tmp/tikv-ctl --db /data/tidb-data/tikv-20160/db unsafe-recover remove-fail-stores -s 6 --all-regions
removing stores [6] from configurations…
success
但是这个节点还是无法重启成功
lmy012
(Lmy012)
2020 年8 月 26 日 07:15
8
另外,执行了删除store,同时把tombstone状态的节点直接删除
» store delete 6
Success!
» store remove-tombstone
Success!
通过tiup cluster display tidb-test 查看,却还能看到这个节点,如果想重新把这个节点扩容回去,会导致一直没办法扩容,报端口、路径冲突。