TIKV 缩容后， io占比100%， 及大量的region 迁移

🪐 TiDB 技术问题
1

【 TiDB 使用环境】生产环境
【 TiDB 版本】 v6.5.3
【复现路径】：
集群5台服务器 ，每台服务器部署3个tikv， 其中两个tikv在机械盘， 1个tikv在ssd盘， TIKV节点共15个 。12月15号 6点~7点之间缩减了一个 机械盘的tikv， 因为内存问题， 17号早上8点20分到 30分之间 再次缩减一个 机械盘的tikv ， 然后监控查看， 从17号开始， 5台服务器的 ssd 磁盘io一直占满100%。 查看日志ssd磁盘上的tikv ， 有大量的 [“failed to send extra message”] 报错 及 大量的region 找不到leader ， 但是根据region id ，可以查看 leader、 还有大量的info 信息 报频繁选举 [“starting a new election”] 。 解决方法：停掉业务应用， 重启tidb 集群没有解决 io 100%问题。

【遇到的问题：问题现象及影响】 ： 查看日志ssd磁盘上的tikv ， 有大量的 [“failed to send extra message”] 报错 及 大量的region 找不到leader ， 但是根据region id ，可以查看 leader、 还有大量的info 信息 报频繁选举 [“starting a new election”] 。 解决方法：停掉业务应用， 重启tidb 集群没有解决 io 100%问题。
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【附件：截图/日志/监控】

image
image1662×806 120 KB

image
image1323×806 22.8 KB

image
image1733×838 142 KB

image
image1859×484 243 KB

麻烦大家有空看看 有没有排查思路和解决方法

2

先扩容一下看看

3

看下这个文章

4

image
image1662×806 120 KB

根据你的描述和现象来看，是你做缩容后会有大量的数据 Region 需要进行迁移，Region Peer 进行复制迁移的过程出现了问题。

  1. 从上面这个图里面可以看到Region 想要向 store id = 546213217 这个tikv节点迁移数据时，出现异常了，而异常的原因上面显式是 Full，请检查这个节点的磁盘空间情况。
  • 通过 tiup ctl:{version} pd -u http://{pd-ip}:{pd-port} store {store-id} 可以查看到具体的机器ip

  1. 你的集群涉及到SSD 和 普通 HDD混合盘节点部署，你有这个机器是做 冷热归档存储吗？Placement Rule 方面的规划和设计什么的？

  2. 确认一下缩容的节点，数据量有多大，涉及要迁移的 Region 数、Leader 等。

  3. 由于存储层涉及大量数据的迁移，所以你重启集群是没有什么效果的，需要解决数据迁移的问题。

  • 如果可以，先进行扩容，提升集群的可用空间，使得集群可以正常进行数据迁移。这个可能是最快恢复的方式。
  • 其次通过 tiup ctl:{version} pd -u http://{pd-ip}:{pd-port} config show 查看集群的 high space ratio 值是多少，然后根据监控判断是否需要适当调大，从而放宽空间相关的调度限制。

楼主可以根据上面的思路和处理方式，先排查和处理。

5

TIKV缩容，原来这个机器上的LEADER都会转移，当然会有大量IO产生

6

机械盘跑到io100%不是很容易吗

7

TIKV节点共15个 。12月15号 6点~7点之间缩减了一个 机械盘的tikv， 因为内存问题， 17号早上8点20分到 30分之间 再次缩减一个 机械盘的tikv

最大的问题是，缩减之前有没有手动先处理好 region leader 的转移，
没有的话，这个操作带来的后果就比较严重

重启是解决不了的，最大的可能：

  1. region leader 无法找回，会导致部分数据永久丢失
  2. region 副本无法选主，带来集群的运行风险
  3. 需要考虑兵行险招，有损恢复这部分 region…
8

此类操作存在一定风险，引此为戒。

9

每台机跑3个tikv，估计label也没做好，容灾做的差，然后缩容又随手开干

10

感觉楼主对这些操作背后的原因和原理都还有比较大的提升空间，一顿操作下来，问题更加棘手了

11

1.首先确定下你的tikv节点打了label没有，是不是tikv节点下线2个之后对应label的节点或者空间不够了，已经无法将对应的leader迁移走了
2.你12月15号 6点~7点之间缩减了一个 机械盘的tikv，当时确定这个节点上的leader都已经迁移到其他节点了吗？不会是没完成迁移强制缩容的吧，然后你17号早上8点20分到 30分之间 再次缩减一个，这时候可能上一个节点的region副本还没补充完，你缩容的第二个节点上刚好有原来缩容的region的副本，导致有些region副本数不够了。。。

12

还没有结果吗?