TIKV节点下线

🪐 TiDB 技术问题
1

【 TiDB 使用环境】生产环境
【 TiDB 版本】6.5.1

我有6个TIKV节点，每个节点6.5T，现在要下线2个TIKV节点，是不是要等很久啊

2

慢慢下呗

3

时间应该挺长，系统不繁忙的话应该会快点

4

缩容呗，要保持服务在线吗，数据量大应该时间挺长啊

5

业务空闲期，慢慢下线

6

如果直接关机一台TIKV，副本会自动复制一份吗

7

没有人工介入时，PD 处理 TiKV 节点故障的默认行为是，等待半小时之后（可通过 max-store-down-time 配置调整），将此节点设置为 Down 状态，并开始为涉及到的 Region 补充副本。

实践中，如果能确定这个节点的故障是不可恢复的，可以立即做下线处理，这样 PD 能尽快补齐副本，降低数据丢失的风险。与之相对，如果确定这个节点是能恢复的，但可能半小时之内来不及，则可以把 max-store-down-time 临时调整为比较大的值，这样能避免超时之后产生不必要的副本补充，造成资源浪费。

自 v5.2.0 起，TiKV 引入了慢节点检测机制。通过对 TiKV 中的请求进行采样，计算出一个范围在 1~100 的分数。当分数大于等于 80 时，该 TiKV 节点会被设置为 slow 状态。可以通过添加 evict-slow-store-scheduler 来针对慢节点进行对应的检测和调度。当检测到有且只有一个 TiKV 节点为慢节点，并且该 TiKV 的 slow score 到达限定值（默认 80）时，将节点上的 Leader 驱逐（其作用类似于 evict-leader-scheduler）。

8

想快就增大下region迁移速度。

9

业务空闲期下吧

10

评估业务空闲期，慢慢来，越着急越出错~

11

是要挺久，着急的话调整region迁移速度，缩容前再预估下剩下的 TiKV 的存储是不是够用

12

1.首先你说的 每个节点6.5T 是你的tikv节点总大小是6.5还是使用了6.5T，如果收缩2个tikv节点。这两个节点的数据需要移动到另外4个节点上。这四个节点有空间没有。
然后开始收缩，
根据我前段时间刚收缩的经验来看：

  1. 执行该节点的 leader_weight 和region_weight 为0 这一步仅仅是让你把这个节点的数据移动走，leader很快几分钟全部移动完了20k，region是最慢的。55k的region我这个服务器移动了24小时。
    store weight 97003106 0 0
    如果速度嫌慢 指定该store 调整传输速度，最大200，业务期间可以调整为50，晚上凌晨可以调整为200
    store limit 97003106 50
    2.查看等两个都是100以内了。执行收缩
    tiup cluster scale-in
1 个赞
13

Starting component cluster: /home/tidb/.tiup/components/cluster/v1.12.1/tiup-cluster scale-in tidb-ali-p -N xxx:20160
This operation will delete the xxx:20160 nodes in tidb-ali-p and all their data.
Do you want to continue? [y/N]:(default=N) y
The component [tikv] will become tombstone, maybe exists in several minutes or hours, after that you can use the prune command to clean it
Do you want to continue? [y/N]:(default=N)

14

没问题吧

15

为什么不用 tiup 下线？

16

就是用的tiup

17

直接关机也可以

18

走正常缩容，慢慢走。

19

下线了没？用了多久 专栏 - TiKV缩容下线异常处理的三板斧 | TiDB 社区

20

没什么问题，这是我之前记录的。最后结果必须有successfully就行
最后隔几分钟执行一遍tiup cluster display 检查是否还在，如果不在了
去pd ctl里面 执行store remove-tombstone
要不然监控里面会有某个tikv挂掉的告警状态

.执行缩容命令： 1分钟结束
tiup cluster scale-in test-cluster --node 172.16.2.28:20160
····················································

  • Regenerate config pd → 172.16.2.31:2379 … Done
  • Regenerate config tikv → 172.16.2.32:20160 … Done
  • Regenerate config tikv → 172.16.2.33:20160 … Done
  • Regenerate config tikv → 172.16.2.34:20160 … Done
  • Regenerate config tidb → 172.16.2.31:4000 … Done
  • Regenerate config prometheus → 172.16.2.31:9090 … Done
  • Regenerate config grafana → 172.16.2.31:3000 … Done
  • Regenerate config alertmanager → 172.16.2.31:9093 … Done
  • [ Serial ] - SystemCtl: host=172.16.2.31 action=reload prometheus-9090.service
    Scaled cluster test-cluster in successfully