TiKV 扩容后 region 不均衡

【 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 的,后面突然就停了

2、region count 也是上不去

【处理方法】

我根据以下文档去操作

一、store 打分

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

二、排查空 region 或者小 region

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

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

但是空 region 还是很多

三、热点负载问题

  • 写热点

  • 读热点

没有明显的热点问题

四、调整 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 了一会,突然又不行了!


五、排查 operator 调度的问题

1、调整调度的参数

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

config set disable-replace-offline-replica true    

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

4、调度器正常

image

【疑问】

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

1 个赞

region 副本数是多少呢?

默认3个

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

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

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、这个下线节点进程已经没有了,是否影响下线呢,能否强制下线呢?

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、但是新扩容的两个节点没有报错

我 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'); 

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

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

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

另外推荐这篇:

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 掉的,然后扩容之后才对它进行缩容的,这个流程是否出错了?
[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

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

你把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 个赞

执行了,没有

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


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

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

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 个赞

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

我发现这个 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

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

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