手动删除tidb-data下面的pd和tikv目录,如何恢复

为提高效率,请提供以下信息,问题描述清晰能够更快得到解决:

【TiDB 版本】

【问题描述】
刚刚进行了一个测试:手动删除tidb-data下的pd和tikv目录后,pd的目录会自动新建一个目录,但是内容相比于原来的目录有缺失,tikv目录不会自动重新建立,集群状态也有问题:
image
使用restart指令重新启动pd组件,失败:
image
image
[2021/02/18 11:07:47.950 +08:00] [FATAL] [main.go:120] [“run server failed”] [error=“[PD:etcd:ErrStartEtcd]member f9386102431de5bc has already been bootstrapped”] [stack=“github.com/pingcap/log.Fatal
\t/home/jenkins/agent/workspace/build_pd_multi_branch_v4.0.10/go/pkg/mod/github.com/pingcap/log@v0.0.0-20200511115504-543df19646ad/global.go:59
main.main
\t/home/jenkins/agent/workspace/build_pd_multi_branch_v4.0.10/go/src/github.com/pingcap/pd/cmd/pd-server/main.go:120
runtime.main
\t/usr/local/go/src/runtime/proc.go:203”]
这个怎么恢复呢?

若提问为性能优化、故障排查类问题,请下载脚本运行。终端输出的打印结果,请务必全选并复制粘贴上传。

可以通过 tiup cluster scale-in --force 的方式缩容掉节点,然后重新扩容节点

额,好的,这个我过会试一下,那个有不缩容扩容,直接修复的方法嘛?:sweat_smile:

数据目录被删除的话,没有办法通过拷贝别的节点的数据之类的方式进行恢复的,数据目录被清空的话,扩缩容节点是推荐的恢复方式。

数据目录没有被清空,我就是想测试一下,把原来的pd-2379和tikv-20160这两个目录备份后,然后删掉了,像模拟一下误操作的,这个也是只有扩容和缩容嘛?:joy:

那你可以试下将目录移回去看下能不能恢复吧

额,。。。。是有这么个道理的,这不现在主要是想模拟一下误操作,删除目录后,该如何恢复的嘛?:rofl:

那就扩缩容

那个,大神,我扩缩容了,pd是比较顺利的,但是tikv不顺利:
脚本:
pd_servers:

  • host: 172.20.146.144

tikv_servers:

  • host: 172.20.146.144
    缩容后:

    扩容后:

    报错:
    [2021/02/18 14:40:34.495 +08:00] [ERROR] [util.rs:347] [“request failed”] [err_code=KV:PD:gRPC] [err=“Grpc(RpcFailure(RpcStatus { status: 2-UNKNOWN, details: Some("duplicated store address: id:10005 address:\"172.20.146.144:20160\" version:\"4.0.10\" status_address:\"172.20.146.144:20180\" git_hash:\"2ea4e608509150f8110b16d6e8af39284ca6c93a\" start_timestamp:1613630434 deploy_path:\"/tidata/tidb-deploy/tikv-20160/bin\" , already registered by id:1 address:\"172.20.146.144:20160\" state:Offline version:\"4.0.10\" status_address:\"172.20.146.144:20180\" git_hash:\"2ea4e608509150f8110b16d6e8af39284ca6c93a\" start_timestamp:1613610928 deploy_path:\"/tidata/tidb-deploy/tikv-20160/bin\" last_heartbeat:1613613814164172934 ") }))”]
    [2021/02/18 14:40:34.495 +08:00] [FATAL] [server.rs:590] [“failed to start node: Grpc(RpcFailure(RpcStatus { status: 2-UNKNOWN, details: Some("duplicated store address: id:10005 address:\"172.20.146.144:20160\" version:\"4.0.10\" status_address:\"172.20.146.144:20180\" git_hash:\"2ea4e608509150f8110b16d6e8af39284ca6c93a\" start_timestamp:1613630434 deploy_path:\"/tidata/tidb-deploy/tikv-20160/bin\" , already registered by id:1 address:\"172.20.146.144:20160\" state:Offline version:\"4.0.10\" status_address:\"172.20.146.144:20180\" git_hash:\"2ea4e608509150f8110b16d6e8af39284ca6c93a\" start_timestamp:1613610928 deploy_path:\"/tidata/tidb-deploy/tikv-20160/bin\" last_heartbeat:1613613814164172934 ") }))”]
    但是我缩容后,我看了一下,tikv的目录都没有了。。。。。怎么还有这个问题的。。。。。
  1. store 的元信息是存储在 pd 中的,报 duplicate store address ,应该是 pd 中对应的节点信息没有被清除。可以通过 pd-ctl 执行 store 命令确认
  2. 可以重新缩容该节点,缩容之后通过 pd-ctl 执行 store 命令确认节点元信息是否被清理,如果没有清理的话,可以通过 curl -X POST http://{pd_ip}:{pd_port}/pd/api/v1/store/${store_id}/state?state=tombstone 命令将对应节点的状态设置为 tombstone ,然后执行 tiup cluster prune 操作清除 tombstone 节点。确认元信息被清理掉之后可以重新扩容。
  3. 另外看到你的集群 tikv 节点是从 3 个节点强制缩容成 1 个节点,在默认 3 副本的情况下,会导致 region 副本不可用,并且可能有数据丢失,具体可以参考下这个帖子:Tidb灾难恢复演练-多副本丢失

1、store后是:感觉好像清理的不干净
store
{
“count”: 3,
“stores”: [
{
“store”: {
“id”: 1,
“address”: “172.20.146.144:20160”,
“state”: 1,
“version”: “4.0.10”,
“status_address”: “172.20.146.144:20180”,
“git_hash”: “2ea4e608509150f8110b16d6e8af39284ca6c93a”,
“start_timestamp”: 1613610928,
“deploy_path”: “/tidata/tidb-deploy/tikv-20160/bin”,
“last_heartbeat”: 1613613814164172934,
“state_name”: “Offline”
},
“status”: {
“capacity”: “10.3GiB”,
“available”: “7.445GiB”,
“used_size”: “31.85MiB”,
“leader_count”: 11,
“leader_weight”: 1,
“leader_score”: 11,
“leader_size”: 11,
“region_count”: 23,
“region_weight”: 1,
“region_score”: 23,
“region_size”: 23,
“start_ts”: “2021-02-18T09:15:28+08:00”,
“last_heartbeat_ts”: “2021-02-18T10:03:34.164172934+08:00”,
“uptime”: “48m6.164172934s”
}
},
{
“store”: {
“id”: 4,
“address”: “172.20.146.145:20160”,
“state”: 1,
“version”: “4.0.10”,
“status_address”: “172.20.146.145:20180”,
“git_hash”: “2ea4e608509150f8110b16d6e8af39284ca6c93a”,
“start_timestamp”: 1612853601,
“deploy_path”: “/tidata/tidb-deploy/tikv-20160/bin”,
“last_heartbeat”: 1612856011555390181,
“state_name”: “Offline”
},
“status”: {
“capacity”: “0B”,
“available”: “0B”,
“used_size”: “0B”,
“leader_count”: 0,
“leader_weight”: 1,
“leader_score”: 0,
“leader_size”: 0,
“region_count”: 23,
“region_weight”: 1,
“region_score”: 23,
“region_size”: 23,
“start_ts”: “2021-02-09T14:53:21+08:00”,
“last_heartbeat_ts”: “2021-02-09T15:33:31.555390181+08:00”,
“uptime”: “40m10.555390181s”
}
},
{
“store”: {
“id”: 5,
“address”: “172.20.146.143:20160”,
“version”: “4.0.10”,
“status_address”: “172.20.146.143:20180”,
“git_hash”: “2ea4e608509150f8110b16d6e8af39284ca6c93a”,
“start_timestamp”: 1613610925,
“deploy_path”: “/tidata/tidb-deploy/tikv-20160/bin”,
“last_heartbeat”: 1613632038142316460,
“state_name”: “Up”
},
“status”: {
“capacity”: “10.3GiB”,
“available”: “6.616GiB”,
“used_size”: “32.19MiB”,
“leader_count”: 12,
“leader_weight”: 1,
“leader_score”: 12,
“leader_size”: 12,
“region_count”: 23,
“region_weight”: 1,
“region_score”: 23,
“region_size”: 23,
“start_ts”: “2021-02-18T09:15:25+08:00”,
“last_heartbeat_ts”: “2021-02-18T15:07:18.14231646+08:00”,
“uptime”: “5h51m53.14231646s”
}
}
]
}

2、我来试一下curl的方法,
3、这个不是要缩容成1个tikv,而是在进行高可用测试的,有点尴尬的是上次就一个tikv弄挂掉后一直没有能扩容成功:joy:

你的集群现在只有一个 tikv 节点是 up 状态,那 region 的状态是不能正常工作的,因为无法满足 raft 多数派,没有 leader ,所以当扩容节点的时候,因为 region 没有 leader 也就无法正常在新节点上补副本出来。

哦,好的,我先用你刚刚上的2先来试试,对了,我想问一下,这个确认元信息被清理掉,指的是对应节点上的tidb-data和tidb-deploy中的tikv的相关目录都没有了,是吧:thinking:

元信息被清理掉指的是 pd-ctl 执行 store 命令没有对应节点 的信息输出。跟对应节点上的目录没有关系。
扩容 tikv 节点的时候,会将新节点注册到 pd 上,所以如果 pd 中的 store 元信息没有清理干净的话,扩容的时候 tikv 节点就会报 duplicate address.

ok,好的,我来试试,辛苦你了

那个,大神,尴尬的一,我使用curl -X POST http://172.20.146.143:2379/pd/api/v1/store/1/state?state=tombstone的结果:


然后使用pd-ctl看了一下后:还是Offline状态

curl -X POST http://{pd_ip}:{pd_port}/pd/api/v1/store/${store_id}/state?state=Tombstone

改下大小写试下

ok,好的,谢谢,这个已经被删了:+1:,我现在扩容一下看看,对了,我刚刚看官网,我可以使用store delete 1这么直接删掉嘛?

大神扩容也好了,我标了一下解决方案,谢谢,辛苦您了!

store delete 是下线 store 节点的操作。
节点是正常的 up 状态下的话,执行 store delete 命令后,节点状态会变为 offline 状态,开启迁移该节点上的 region(需要 tikv 进程是运行状态),等待节点上的 region 都迁移完成之后,该节点的状态会变成 tombstone 状态,表示下线完成。

你刚才的那种情况,tikv 进程已经异常了,无法通过正常的 store delete 操作下线掉节点的。