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

[变又未变]

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

【TiDB 版本】

【问题描述】
刚刚进行了一个测试：手动删除tidb-data下的pd和tikv目录后，pd的目录会自动新建一个目录，但是内容相比于原来的目录有缺失，tikv目录不会自动重新建立，集群状态也有问题：

使用restart指令重新启动pd组件，失败：


[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”]
这个怎么恢复呢？

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

[GangShen]

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

[变又未变]

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

[GangShen]

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

[变又未变]

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

[GangShen]

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

[变又未变]

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

[GangShen]

那就扩缩容

[变又未变]

那个，大神，我扩缩容了，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的目录都没有了。。。。。怎么还有这个问题的。。。。。

[GangShen]

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弄挂掉后一直没有能扩容成功

[GangShen]

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

[变又未变]

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

[GangShen]

元信息被清理掉指的是 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状态

[GangShen]

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

改下大小写试下

[变又未变]

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

[变又未变]

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

[GangShen]

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

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