TiKV下线速度慢，而且数据不可用

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

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

  • 【TiDB 版本】：2.1.5
  • 【问题描述】：集群包含2个TiDB节点和1个TiPD节点，6个TIKV节点。下线2个TIKV节点时，数据迁移速度较慢，而且造成线上数据访问失败的问题。
    发现数据库无法返回结果后，打算先终止迁移，停止上述两个节点的服务。
    发生报错：
    TASK [command] ****************************************************************************************************************************************
    fatal: [10.160..]: FAILED! => {“changed”: false, “cmd”: [“cat”, “/search/data/deploy/status/tikv.pid”], “delta”: “0:00:00.643338”, “end”: “2020-09-04 11:09:46.602947”, “msg”: “non-zero return code”, “rc”: 1, “start”: “2020-09-04 11:09:45.959609”, “stderr”: “cat: /search/data/deploy/status/tikv.pid: No such file or directory”, “stderr_lines”: [“cat: /search/data/deploy/status/tikv.pid: No such file or directory”], “stdout”: “”, “stdout_lines”: []}

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

2

您好 请您先检查下 TiDB 监控面板中 PD 监控中 cluster 监控类的

  • Abnormal stores：处于异常状态的节点数目，正常情况应当为 0
  • Region health：每个 Region 的状态，通常情况下，pending 的 peer 应该少于 100，miss 的 peer 不能一直大于 0
    找到异常 TiKV 节点,并重启 TiKV 相关服务
    如果没有删除原节点数据文件等内容，可以通过以下命令将下线节点状态变为 up。 curl -X POST http://${pd_ip}:2379/pd/api/v1/store/${store_id}/state?state=Up 如果已经删除了原节点数据文件，是会造成部分数据丢失的情况。
3

pending current 是33.7k
miss peer 目前是770

4

image
image1624×574 55.3 KB

5

刚才使用命令查看store状态
./resources/bin/pd-ctl -u “http://${pd_ip}:2379” -d store

image
image868×832 36.1 KB

发现511127还活着，使用你提供的UP命令，无法重新上线这个TIKV，命令返回null

6

image
image3276×762 213 KB

使用命令查看store状态，发现两台TIKV处于DOWN状态，使用 ansible-playbook start.yml -l ip1,ip2命令重启报错

7

image
TIKV 节点log显示：
E0215 03:58:37.929248293 270453 chttp2_transport.c:1143] Received a GOAWAY with error code ENHANCE_YOUR_CALM and debug data equal to “too_many_pings”
E0215 04:15:24.498225477 270453 chttp2_transport.c:1143] Received a GOAWAY with error code ENHANCE_YOUR_CALM and debug data equal to “too_many_pings”
thread panicked while processing panic. aborting.

8

从 您上传的图片看 PD 中记录的 Store 节点已经下线.
请检查 PD 监控面板 Region health

  • Region health：每个 Region 的状态，通常情况下，pending 的 peer 应该少于 100，miss 的 peer 不能一直大于 0
    down stores 经过 10 分钟后 即会转变为 tombstone stores [墓碑节点]. 后续可以通过 pd-ctl 将 此类节点清理

关于 ansiable 启动失败的报错只的是 node_exporter 组件启动失败,此组件为服务监控组件 .有可能是在之前的缩容过程中此服务以被清理导致启动失败.
可以登录 已下线主机 检查 systemctl list-units 中的 tikv | node_export | blackbox_exporter 组件是否都清理干净.

9

下线的两个TIKV节点平均8w的region数目，目前处于DOWN状态，而且region_size不断在减少，但是速度很慢。我猜测是正在做region迁移。能否有办法终止这种region迁移，重新上线这两个TIKV？
ansiable 启动失败您提到是因为 node_exporter 组件启动失败，是否通过登录主机清理现存的node_export进程，就可以重新启动DOWN状态的TIKV？

10

node_exporter-9100.service loaded activating auto-restart node_exporter-9100 service
确实存活，需要stop?

11

您好 首先需要您检查 您下线的 tikv 服务器的 tikv 相关服务是否已清理,如果服务依然存在可以手动将 服务拉起
类似
systemctl start tikv-XXXX.service 这种
之后使用
curl -X POST http://${pd_ip}:2379/pd/api/v1/store/${store_id}/state?state=Up 将 store 状态 手动修改为 UP 观察下后续情况.
store_id 可以通过 pd-ctl store 命令获取

12

这是 tidb 监控组件 ,tikv 节点拉起后 可以手动将此服务进行 restart

13

“您下线的 tikv 服务器的 tikv 相关服务是否已清理” 这个如何检查？如果清理了，该怎么重启。
另外，node_exporter-9100.service和blackbox_exporter-9115 service始终处于activating auto-restart状态

14

Tikv节点如何拉起？

15

目前这两个 tikv 实例还是处于 offline 状态还是 tombstone 状态？如果是 offline 状态上面的 region_size 还在不断减少吗？

16

目前这俩个实例状态是DOWN，一直不变，而且size没有变少。在服务机上，tikv | node_export | blackbox_exporter 组件全部都被清理了。
这种情况如何处理，目前数据库可以连接，但是无法进行表查询

17
  1. 当时是如何下线两个 tikv 的，看您的描述应该感觉是 两个 tikv 同时 down 了，如果是3副本，那有两副本已经出问题了，会导致有一些落在这两个tikv的region丢失两副本，无法使用。
  2. 如果这两个tikv无法恢复了，可以参考 https://docs.pingcap.com/zh/tidb/stable/tikv-control#强制-region-从多副本失败状态恢复服务 尝试恢复。
18

首先是正常缩容（6-2=4），两个TIKV同时进入offline状态，结果发现速度太慢，打算暂停缩容，使用命令ansible-playbook stop.yml停止两台TIKV运行，发现命令执行失败。期间状态始终处于offline状态。根据TIDB技术支持的提示，在服务机器使用systemctl start 启停tikv | node_export | blackbox_exporter 组件，发现并没有启动，组件始终处于 activating auto-restart 状态。期间节点状态变化为DOWN。

19

tikv-ctl --db /path/to/tikv/db unsafe-recover remove-fail-stores -s 4,5 --all-regions
这个命令需要在正常的tikv节点上执行？
我看tikv节点上没有这个命令或者脚本，另外“/search/tidb/deploy/data/db”这个是tikv的sst文件保存的路径，命令中的路径指的是这个吗？

20
  1. tikv-ctl 可以从中控机下 scp 到每个节点
  2. 参考这个文档

https://asktug.com/t/topic/36199