tikv下线产生learner-peer 和 pending-peer

🪐 TiDB 技术问题 部署&运维管理
1

为提高效率，提问时请提供以下信息，问题描述清晰可优先响应。

  • 【TiDB 版本】：v3.0.0
  • 【问题描述】：（集群是有arm和x86的机器的混合，之前上线了几个arm 的tikv）现在做x86 tikv节点下线过程中有一些region 无法下线，于是手动执行了operator add transfer-leader operator add remove-peer operator add add-peer 等操作，但是发现补充副本后一直是learner状态，目前集群中还有一些learner_peer 和pending_peer状态的region，这个是如何产生的？如何处理掉？
    之前为了快速下线修改了 max-pending-peer-count max-snapshot-count replica-schedule-limit参数
    image
    image1819×272 23.3 KB

    image
    image846×674 9.34 KB

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

1 个赞
2

1、请详细描述下上线以及下线 store 的情况，是一个 store 未下线成功，即状态没有变成 tombstone，就下线了另一个 store 吗？

2、使用 pd-ctl 检查下 pending region 的情况，参考命令如下：

image
image1582×944 73.2 KB

https://pingcap.com/docs-cn/stable/reference/tools/pd-control/#region-check-miss-peer--extra-peer--down-peer--pending-peer--incorrect-ns

1 个赞
3

昨天下线了一个tikv，有leader，region没有迁移完，今天手动把这些给迁移了，这个节点上的副本给删除了，下线成功了，但是现在补充副本的时候都是learner状态，这些怎么处理

image
image772×675 8.7 KB

如果我还要下线store4，会不会发生数据丢失

1 个赞
4

1、先提供下 store 状态信息吧，使用 pd-ctl store 查看

2、数据安全起见，目前不要再下线 store 4

1 个赞
5

{
“count”: 4,
“stores”: [
{
“store”: {
“id”: 16002,
“address”: “10.x.x.x:20160”,
“version”: “3.0.0”,
“state_name”: “Up”
},
“status”: {
“capacity”: “81 GiB”,
“available”: “69 GiB”,
“leader_count”: 265,
“leader_weight”: 1,
“leader_score”: 8035,
“leader_size”: 8035,
“region_count”: 759,
“region_weight”: 1,
“region_score”: 28620,
“region_size”: 28620,
“receiving_snap_count”: 12,
“start_ts”: “2020-01-20T09:59:53+08:00”,
“last_heartbeat_ts”: “2020-02-04T17:19:28.225285613+08:00”,
“uptime”: “367h19m35.225285613s”
}
},
{
“store”: {
“id”: 16001,
“address”: “10.x.x.x:20160”,
“version”: “3.0.0”,
“state_name”: “Up”
},
“status”: {
“capacity”: “81 GiB”,
“available”: “74 GiB”,
“leader_count”: 313,
“leader_weight”: 1,
“leader_score”: 7569,
“leader_size”: 7569,
“region_count”: 465,
“region_weight”: 1,
“region_score”: 22640,
“region_size”: 22640,
“receiving_snap_count”: 12,
“start_ts”: “2020-01-20T09:59:53+08:00”,
“last_heartbeat_ts”: “2020-02-04T17:19:28.126131059+08:00”,
“uptime”: “367h19m35.126131059s”
}
},
{
“store”: {
“id”: 16003,
“address”: “10.126.4.45:20160”,
“version”: “3.0.0”,
“state_name”: “Up”
},
“status”: {
“capacity”: “81 GiB”,
“available”: “65 GiB”,
“leader_count”: 291,
“leader_weight”: 1,
“leader_score”: 7703,
“leader_size”: 7703,
“region_count”: 960,
“region_weight”: 1,
“region_score”: 33755,
“region_size”: 33755,
“receiving_snap_count”: 4,
“start_ts”: “2020-02-03T20:06:32+08:00”,
“last_heartbeat_ts”: “2020-02-04T17:19:30.627221026+08:00”,
“uptime”: “21h12m58.627221026s”
}
},
{
“store”: {
“id”: 4,
“address”: “10.x.x.x:20160”,
“version”: “3.0.0”,
“state_name”: “Up”
},
“status”: {
“capacity”: “98 GiB”,
“available”: “49 GiB”,
“leader_count”: 180,
“leader_weight”: 1,
“leader_score”: 17952,
“leader_size”: 17952,
“region_count”: 963,
“region_weight”: 1,
“region_score”: 38762,
“region_size”: 38762,
“sending_snap_count”: 33,
“start_ts”: “2020-01-19T17:03:19+08:00”,
“last_heartbeat_ts”: “2020-02-04T17:19:30.660750361+08:00”,
“uptime”: “384h16m11.660750361s”
}
}
]
}

1 个赞
6

来个图，看的清晰点

image
image1880×2003 172 KB

1 个赞
7

1、从 store 信息看，现在一共 4 个 store，并且都是 Up 状态，计划下线 store id 为 4 的节点

2、昨天下线的是 store id 是几，在上面的 store 信息没有看到 tombstone 状态的节点，是做过特殊处理吗？

1 个赞
8

昨天下线的是store1 ,我今天手动把leader region 迁移完成后，已经执行了 缩容的停止和滚动promethues操作，再说tombstone在这也不会显示吧，现在的问题是，增加的副本都是learner的,这种数据怎么能变成正常状态，我们后续还是要下线store4的

1 个赞
9

1、查看 store 是想了解下上下线前 store 的状态及节点数量。

2、再确认下，昨天只下线了一个 store 1，包括 store 1 一共下线了几个节点，下线节点操作完成后，使用下述命令确认过，下线的 store 都正常下线了吗？在第一次下线操作前，整个集群应该是 3 个 x86，3 个 arm 吧？

pd-ctl -u "http://pd-ip:pd-port" -d store store-id ---- 被下线 store 变为 tombstone

3、如果是正常下线，会 transfer 被下线节点的 leader 到其他 Up 的 store。如果是被下线节点的 region 的 follower 角色的 peer 要调度，原则上会自动补足副本，在被调度的目标 store 添加下线 store 中 region 的 peer，此时 region 有 4 个 peer，当新加的 peer 追上 leader，则角色会由 learner 变成 follower。再将被下线节点上的角色为 follower 的 peer 删除。

4、如果是在下线时出现 region count 不为 0 的情况，手动的操作某个 region 的 peer，建议的操作步骤如下：

1) 使用 add peer 的命令，在 Up 状态的 store 添加一个 peer
2）等待该 peer 的状态变为 follower 
3）使用 remove-peer 将被下线的 store 上的 region 对应的 peer 删除

待 region 的一个 peer 操作完成后，再次重复上述操作，操作该 region 的另一个 peer

5、你那里在 remove ，add peer 的时候，具体的操作流程是什么？是同时下线了两个 store ，手动的把 region 的 peer ，先从被下线的 store remove了，再往 up 的 store add 了一个 peer，此时这个新增的 peer 还没变成 follower 状态，紧接着对同一个 region 的另一个 peer 也先 remove 后 add，做了相同的操作吗？

1 个赞
10

节前是下线了一个节点，也是下线后很长时间有部分region没有迁移完成，然后手动迁移的，我是先remove ，然后add 的peer，对于leader 是先transfer了，然后remove的再add的， 同一个region的peer好像不能同时操作
也就是说节前操作后应该就有这种learner和pending的peer了
这是下线的两个x86的 tikv

image
image490×587 8.66 KB

1 个赞
11

目前这种情况应该怎么处理啊，我看还有180条这样的数据

image
image1829×256 21.2 KB

12

1、remove 以及 add 一共操作了多少个 region？

2、现在大概率可能是存在某些 region 的 peer 未变成 follower，就操作了该 region 的另一个 peer，导致出现这个问题

3、针对这个问题先做如下操作：

1）先不要下线 store 4 
2）提供下 region id 是 7509，并且状态为 learner 的 store 16001 和 16002 节点中该 region 的日志信息。
3）尝试使用 pd-ctl operator add add-peer 7509 16001 试下，看是否能把 learner 提升为正常 peer
1 个赞
14

1.应该有100多个

image
image584×682 8.18 KB

tikv.log.rar (779.2 KB)

1 个赞
15

尝试使用 pd-ctl operator add add-peer 7509 16001 试下，看是否能把 learner 提升为正常 peer

16

image

17

加了一个16003 还是learner

image
image616×796 10 KB

18

在 16003 新添加的 peer 后，现在再看下 region 7509 的状态是怎样的 ？

19

image
image582×770 9.1 KB

20

1、store 16003 上，把 tikv 日志也发下吧

2、store 4 上，把 tikv 日志也发下吧

21

tikv-16003.rar (794 字节)