TiKV 扩容后 region 不均衡

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

【 TiDB 集群 】

  • PD ：3个
  • TiDB：2个
  • TIkV：5个（原来）=> 7个（扩容后）

【 TiDB 版本】

  • v5.1.1

【操作步骤】

1、因为有个 TiKV 节点（24）有问题，所以把它手动 stop 掉了，状态是 DOWN

2、在 23、24 两个机器扩容多两个 tikv 实例

3、缩容有问题的 TiKV 节点（24），状态是 Pending Offline

4、display 集群情况

192.168.1.17:20160  tikv    linux/x86_64  Up               
192.168.1.18:20160  tikv    linux/x86_64  Up               
192.168.1.22:20160  tikv    linux/x86_64  Up               
192.168.1.23:20160  tikv    linux/x86_64  Up               
192.168.1.23:20161  tikv    linux/x86_64  Up（扩容）               
192.168.1.24:20160  tikv    linux/x86_64  Pending Offline（缩容）  
192.168.1.24:20161  tikv    linux/x86_64  Up（扩容）

【遇到的问题】

1、刚扩容的时候是有在 blance region 的，后面突然就停了

image
image912×256 28.1 KB

2、region count 也是上不去

image
image919×226 24.7 KB

【处理方法】

我根据以下文档去操作

一、store 打分

新扩容的节点分数较低，合理

image
image895×218 27.1 KB

二、排查空 region 或者小 region

开启了 region merge ，并且调大了这些值

"max-merge-region-keys": 50000,
"max-merge-region-size": 10,

但是空 region 还是很多

image
image849×253 24.5 KB

三、热点负载问题

  • 写热点

image
image913×262 46.4 KB

  • 读热点

image
image920×287 42.8 KB

没有明显的热点问题

四、调整 leader-weight 和 region-weight

1、在新扩容的两个节点调整权重 leader = 1 ，region = 2

{"id":1343129094,"address":"192.168.1.23:20161","state_name":"Up","capacity":"1.455TiB","available":"1.381TiB","used_size":"190.3MiB","region_count":92,"region_size":841,"leader_count":52,"leader_size":544,"region_weight":2,"leader_weight":1}
{"id":1343129301,"address":"192.168.1.24:20161","state_name":"Up","capacity":"1.455TiB","available":"1.381TiB","used_size":"1007MiB","region_count":103,"region_size":4232,"leader_count":67,"leader_size":3101,"region_weight":2,"leader_weight":1}

2、刚调整的时候 balance 了一会，突然又不行了！

image
image896×244 27.3 KB

image
image911×216 25.7 KB

五、排查 operator 调度的问题

1、调整调度的参数

image
image452×560 21.6 KB

2、怀疑是原来 24 TIKV 节点缩容占用资源，所以把 offline 也关掉了

config set disable-replace-offline-replica true

3、cpu 使用情况还好，都是很高配置的服务器

image
image904×301 43.9 KB

4、调度器正常

image

【疑问】

现在的情况是上线新节点不行，下线旧的节点也不行，请问有什么办法解决吗，以上推荐的方法都已经排查过了，不知道还有没有什么漏洞没有排查，希望大神们帮忙看看！

1 个赞
2

region 副本数是多少呢？

3

默认3个

4
  1. 优先解决下线节点的问题，看看下线的节点 是否 还有region 的 leader，如果有 region leader 先进行迁移
  2. 加速下线节点的region 迁移，帮助下线完成之后，再来处理 empty region 的问题
  3. 通过调整 PD 一些调度参数，来满足 region 合并的需求，待合并完成之后参数还原，再来处理 region 分布不均的问题

这些问题最好一步步的处理…

5

1、下线的节点 leader 已经没了，不过很奇怪，明明我已经下线了两天了，这个 region count 居然还在增长

  • 我早上 9 点查看下线节点的 region count = 47470
{"id":1006624325,"address":"192.168.1.24:20160","state_name":"Offline","capacity":"0B","available":"0B","used_size":"0B","region_count":47470,"region_size":3356788,"leader_count":0,"leader_size":0,"region_weight":1,"leader_weight":1}
  • 刚刚我查看到的 region count = 47518
{"id":1006624325,"address":"192.168.1.24:20160","state_name":"Offline","capacity":"0B","available":"0B","used_size":"0B","region_count":47518,"region_size":3360487,"leader_count":0,"leader_size":0,"region_weight":1,"leader_weight":1}

2、这个下线节点进程已经没有了，是否影响下线呢，能否强制下线呢？

6

1、其他原有的 tikv 节点报错：

[2022/06/17 14:41:56.554 +08:00] [ERROR] [peer.rs:3506] ["failed to send extra message"] [err_code=KV:Raftstore:Transport] [err=Transport(Full)] [target="id: 1342871147 store_id: 1006624325"] [peer_id=1321014496] [region_id=1314142866] [type=MsgHibernateRequest]
[2022/06/17 14:41:56.690 +08:00] [ERROR] [peer.rs:3506] ["failed to send extra message"] [err_code=KV:Raftstore:Transport] [err=Transport(Full)] [target="id: 1342887108 store_id: 1006624325"] [peer_id=1338000854] [region_id=1338000851] [type=MsgHibernateRequest]

2、但是新扩容的两个节点没有报错

7

我 SQL 查询发现这个节点的 region 基本上都是 DOWN 的，有几个是 PENDING 的

SELECT
    p.region_id,
    p.peer_id,
    p.store_id,
    p.status,
    m.ADDRESS,
    s.db_name,
    s.table_name 
FROM
    TIKV_REGION_STATUS s 
    JOIN TIKV_REGION_PEERS p ON s.region_id = p.region_id 
    JOIN TIKV_STORE_STATUS m ON m.store_id = p.store_id 
WHERE 
      p.STORE_ID=1006624325 and p.`STATUS` not in ('DOWN','PENDING');
8

你可以看看这些 region 是关联哪些表的，是否影响你的业务

region 本身的构成就比较复杂，会收到 副本数量，以及本身节点是否支持副本调度等等影响
需要逐个排查

参考下官网
https://docs.pingcap.com/zh/tidb/stable/pd-scheduling-best-practices#节点下线速度慢

另外推荐这篇：

9

1、涉及到很多表，读写不应该都是在 leader 上面吗，我看这个节点的 leader 已经没了，为什么其他 region 无法迁移

2、 https://docs.pingcap.com/zh/tidb/stable/pd-scheduling-best-practices#节点下线速度慢 这个在上面已经排查过了

3、我根据下线 pending offline 文章进行排查

  • 存活节点肯定大于 3个
  • pd 的日志有显示两个 tikv 节点容量不够的问题，但是其它节点是充足的
[2022/06/17 14:36:46.931 +08:00] [WARN] [cluster.go:513] ["store does not have enough disk space"] [store-id=1031573974] [capacity=787438190592] [available=114353913856]
[2022/06/17 14:36:51.338 +08:00] [WARN] [cluster.go:513] ["store does not have enough disk space"] [store-id=1] [capacity=1913806786560] [available=166896963584]

image

  • 其他 tikv 节点能够连上 pd，我在怀疑是不是因为缩容的节点并不存活导致的，因为这个节点有问题，我才选择把它 stop 掉的，然后扩容之后才对它进行缩容的，这个流程是否出错了？
10 
[2022/06/17 14:36:46.931 +08:00] [WARN] [cluster.go:513] ["store does not have enough disk space"] [store-id=1031573974] [capacity=787438190592] [available=114353913856]
[2022/06/17 14:36:51.338 +08:00] [WARN] [cluster.go:513] ["store does not have enough disk space"] [store-id=1] [capacity=1913806786560] [available=166896963584]

low-space-ratio默认值是0.8，看你这个告警，有2个store的剩余容量低于20%了，PD会避免向上面调度region

11

嗯嗯，这个我知道，但是其他节点是足够的
image

12

你把pending offline那台down掉以后，查一下看有没有region的peer数量少于3个

tiup ctl:v5.1.1 pd region --pd <PD_IP>:2379 --jq '.regions[] | {id: .id, peer_stores: [.peers[].store_id] | select(length<3)}'

1 个赞
13

执行了，没有

image
image1873×95 13.5 KB

14

如果确定是无效的 region，可以手动移除，参考

image
image758×609 27.8 KB

缩容操作之前，要考虑当前的节点上的副本数是否能够满足基础的运行要求，不然会出现不调度的情况
正确的操作：

  1. 先扩容，然后将你需要驱逐的节点上的region 进行平移
  2. 在缩容
  3. 观察缩容结果
15

OK，首先确保你那个节点是DOWN的状态，然后确认一下PD中是否还记录了有peer在1006624325这个store上。正常情况下如果store是DOWN掉的，PD会在半个小时后在其它store上补齐副本

tiup ctl:v5.1.1 pd region --pd <PD_IP>:2379 --jq '.regions[] | {id: .id, peer_stores: [.peers[].store_id] | select(any(.==1006624325))}'

如果还存在副本位于1006624325上面，则用下面脚本为每个位于该store上的副本生成一个remove-peer的命令，然后执行这些命令

tiup ctl:v5.1.1 pd region --pd <PD_IP>:2379 --jq '.regions[] | {id: .id, peer_stores: [.peers[].store_id] | select(any(.==1006624325))}' | grep -v ^$ | awk -F: '{print $2}' | awk -F, '{print $1'} | awk '{print "tiup ctl:v5.1.1 pd operator add remove-peer",$0,"1006624325"}'
1 个赞
16

好的，我试试，remove peer 之后大概多久重新在其他 store 生成副本呢

17

我发现这个 store 1006624325 （192.168.1.24:20160）的 region 一直在增加，但是进程已经是没有的

[root@localhost ~]# ps -ef|grep tikv
tidb     35162     1  3 Jun15 ?        01:54:12 bin/tikv-server --addr 0.0.0.0:20161 --advertise-addr 192.168.1.24:20161 --status-addr 0.0.0.0:20181 --advertise-status-addr 192.168.1.24:20181 --pd 192.168.1.20:2379,192.168.1.21:2379,192.168.1.147:2379 --data-dir /data/tikv/data --config conf/tikv.toml --log-file /data/tikv/log/tikv.log
root     50280 17471  0 18:53 pts/0    00:00:00 grep --color=auto tikv
18

image
image912×224 27.1 KB

19

实测remove peer以后，很快就在其它restore上创建peer了。所以如果remove peer很多的话，最好分批，并留意监控

20

为什么喔 remove peer 之后，隔了两天了，还是没有在其他机器补充副本的，我是查 TIKV_REGION_PEERS 这张表的，peer 自从 remove 之后一直是两个，pd 不是会自动补充吗