tikv缩容和扩容问题

GangShen · 2021 年4 月 19 日 07:48

暂时没有 curl 命令。
不是通过 tiup 部署的话，你们是通过什么方式部署集群的？

wendywong37579080 · 2021 年4 月 19 日 07:49

手工部署的

GangShen · 2021 年4 月 19 日 08:14

停止 tikv 进程
通过 api 设置节点状态为 tombstone: curl -X POST http://{pd_ip}:2379/pd/api/v1/store/${store_id}/state?state=Tombstone
通过 pd-ctl 执行 remove-tombstone 命令清理掉 tombstone 的节点
最后可以清理对应的数据目录和日志目录

wendywong37579080 · 2021 年4 月 20 日 00:39

1.停止
2.curl -X POST http://${pd_id}:${pd_port}/pd/api/v1/store/5/state?state=Tombstone
null
3.» store 5
{
“store”: {
“id”: 5,
“last_heartbeat”: 1618840421338921271,
“state_name”: “Tombstone”
},
“status”: {
“capacity”: “845.3GiB”,
“available”: “810.3GiB”,
“used_size”: “32.06MiB”,
“leader_count”: 0,
“leader_weight”: 1,
“leader_score”: 0,
“leader_size”: 0,
“region_count”: 3,
“region_weight”: 1,
“region_score”: 3,
“region_size”: 3,
“start_ts”: “2021-04-18T10:11:07+08:00”,
“last_heartbeat_ts”: “2021-04-19T21:53:41.338921271+08:00”,
“uptime”: “35h42m34.338921271s”
}
}

» store remove-tombstone
Success!

4.» region 84
{
“id”: 84,
“start_key”: “7480000000000000FF2900000000000000F8”,
“end_key”: “7480000000000000FF2B00000000000000F8”,
“epoch”: {
“conf_ver”: 5,
“version”: 21
},
“peers”: [
{
“id”: 85,
“store_id”: 1
},
{
“id”: 86,
“store_id”: 4
},
{
“id”: 87,
“store_id”: 5
}
],
“leader”: {
“id”: 85,
“store_id”: 1
},
“pending_peers”: [
{
“id”: 87,
“store_id”: 5
}
** ]**,
“written_bytes”: 0,
“read_bytes”: 0,
“written_keys”: 0,
“read_keys”: 0,
“approximate_size”: 1,
“approximate_keys”: 7166
}

过了10个小时，还是一样的，此时执行store命令，已经看不到store 5的信息，但是 region 84的信息还是一样，没有变化。如上

wendywong37579080 · 2021 年4 月 20 日 02:53

这个问题是否彻底的解决办法，感觉是隐患不散的样子

wendywong37579080 · 2021 年4 月 20 日 02:55

» operator show region
[
“replace-offline-replica {mv peer: store [4] to [2117]} (kind:region,replica, region:12(3,5), createAt:2021-04-20 10:46:04.188241806 +0800 CST m=+1552683.613517597, startAt:2021-04-20 10:46:04.188398778 +0800 CST m=+1552683.613674590, currentStep:0, steps:[add learner peer 10691 on store 2117, promote learner peer 10691 on store 2117 to voter, remove peer on store 4])”,
“replace-offline-replica {mv peer: store [4] to [2117]} (kind:region,replica, region:76(19,5), createAt:2021-04-20 10:46:04.189523092 +0800 CST m=+1552683.614798845, startAt:2021-04-20 10:46:04.189561724 +0800 CST m=+1552683.614837484, currentStep:0, steps:[add learner peer 10692 on store 2117, promote learner peer 10692 on store 2117 to voter, remove peer on store 4])”,
“replace-offline-replica {mv peer: store [4] to [2117]} (kind:region,replica, region:84(21,5), createAt:2021-04-20 10:46:43.127716195 +0800 CST m=+1552722.552991987, startAt:2021-04-20 10:46:43.127855712 +0800 CST m=+1552722.553131524, currentStep:0, steps:[add learner peer 10693 on store 2117, promote learner peer 10693 on store 2117 to voter, remove peer on store 4])”
]

» region check 84
Failed to get region: [404] 404 page not found

» operator add remove-peer 84 5
Failed! [500] “failed to add operator, maybe already have one”

这个能说明scheduler有问题 ?
并且，在region 84在store 4上的peer 我现在就不敢操作了，否则这个region 就不能写数据。

GangShen · 2021 年4 月 20 日 07:16

从日志中有看到 region 84 是有不断尝试在别节点上添加副本的 operator 但是没有添加成功，这个可能是被 store4 的 offline peer 阻塞了

可以考虑将 enable-replace-offline-replica 设为 false ，然后再删除 region 上的 operator (operator remove region_id)，再尝试手动在其他节点上添加副本，看能否添加成功。

wendywong37579080 · 2021 年4 月 20 日 07:59

其实前面回复有执行过，并贴出执行步骤和日志。

jiyf · 2021 年4 月 20 日 08:04

关闭 tikv，然后执行

./tikv-ctl --db /tikv_path/data/db unsafe-recover remove-fail-stores -s 5 -r 84 

启动 tikv，这样呢？

jiyf · 2021 年4 月 20 日 08:06

在 store id 为 1 的 tikv上执行。启动后再查询 reigon 84 信息

wendywong37579080 · 2021 年4 月 20 日 08:08

这种情况下 region 84的数据不可以访问，是吧

wendywong37579080 · 2021 年4 月 20 日 08:12

此时把store 1的tikv进程关闭掉

» region 84
{
“id”: 84,
“start_key”: “7480000000000000FF2900000000000000F8”,
“end_key”: “7480000000000000FF2B00000000000000F8”,
“epoch”: {
“conf_ver”: 5,
“version”: 21
},
“peers”: [
{
“id”: 85,
“store_id”: 1
},
{
“id”: 86,
“store_id”: 4
},
{
“id”: 87,
“store_id”: 5
}
],
“leader”: {
“id”: 85,
“store_id”: 1
},
“pending_peers”: [
{
“id”: 87,
“store_id”: 5
}
],
“written_bytes”: 0,
“read_bytes”: 0,
“written_keys”: 0,
“read_keys”: 0,
“approximate_size”: 1,
“approximate_keys”: 7166
}

过了几分钟，此时region 84的leader还是显示在store 1上，跟僵尸一样，peer信息都不动

jiyf · 2021 年4 月 20 日 08:12

现在 region 84三副本，store 4 和 5 上的副本都有问题，是不可访问。上面操作是把 region 84 的在 store 5 上的副本去掉，你同样的执行：./tikv-ctl --db /tikv_path/data/db unsafe-recover remove-fail-stores -s 4 -r 84 去掉 store 4 上的副本

执行下试试呢？

jiyf · 2021 年4 月 20 日 08:16

关闭 store 1 的 tikv
在 store 1机器上，执行：
./tikv-ctl --db /tikv_path_store_1/data/db unsafe-recover remove-fail-stores -s 5 -r 84
./tikv-ctl --db /tikv_path_store_1/data/db unsafe-recover remove-fail-stores -s 4 -r 84
3.启动 store 1 的 tikv
4.pd 查看 region 84

wendywong37579080 · 2021 年4 月 20 日 08:16

» region 84
{
“id”: 84,
“start_key”: “7480000000000000FF2900000000000000F8”,
“end_key”: “7480000000000000FF2B00000000000000F8”,
“epoch”: {
“conf_ver”: 9,
“version”: 21
},
“peers”: [
{
“id”: 85,
“store_id”: 1
},
{
“id”: 10793,
“store_id”: 2117
},
{
“id”: 10794,
“store_id”: 5888
}
],
“leader”: {
“id”: 85,
“store_id”: 1
},
“written_bytes”: 740,
“read_bytes”: 0,
“written_keys”: 2,
“read_keys”: 0,
“approximate_size”: 1,
"

wendywong37579080 · 2021 年4 月 20 日 08:18

目前看是正常的，region 84 不断向其他是store 添加副本的原因是什么呢？什么原因导致的？怎么监控到这种情况？

jiyf · 2021 年4 月 20 日 08:18

这显示就正常了吧

jiyf · 2021 年4 月 20 日 08:24

因为有peer不正常，pd就会尝试加副本。但是region 84处于大多数副本异常状态，然后添加副本失败呢。

在 grafana 看 pd 的面板 region status，可以看到region情况。

wendywong37579080 · 2021 年4 月 20 日 08:29

这监控很重要

wendywong37579080 · 2021 年4 月 20 日 08:34

如果3个tikv节点的集群，挂了一个tikv节点，此时也无法满足三副本的存放。
假如此时把deleted的两个 tikv进程停掉，然后再 store delete 动作，岂不是会正常了？