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

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

  • 【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参数

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

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

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

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

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

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

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

{ “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、从 store 信息看,现在一共 4 个 store,并且都是 Up 状态,计划下线 store id 为 4 的节点

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

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

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,做了相同的操作吗?

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

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

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.应该有100多个

tikv.log.rar (779.2 KB)

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

image

加了一个16003 还是learner

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

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

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

tikv-16003.rar (794 字节)