作者： shangguan86 原文来源：https://tidb.net/blog/57ae6650

故障影响

公司所有的 TIDB 集群集群不可用, 涉及多个业务线: 支付、视频、数据分析、用户等多个业务。

业务流量监控图:

系统负载

备份任开始时间

登录服务器

df -h 直接夯死

根据 cpu 负载以及 duration 的时间基本判断是 ceph 导致的问题。

BR 备份原理:

TIDB 是分布式的数据库, 因此备份也是分布式的。TIDB 每天夜晚零晨都会使用 TIDB 备份组件 BR 进行一次全量备份 ; 使用 BR 备份依赖于所有 TiKV 节点都有一个共享文件系统详情如下图:

使用 ceph 挂载到 tidb 的机器做共享文件。

如下图所示:

当前 TIDB 部署架构

排查过程

问题疑问

df -h 直接夯死把机器挂载点卸载是否可以解决?

umount -l /data/local_backup

强制卸载机器上所有的挂载点，业务方还是无法访问。

排查 TIDB 相关日志

pd、tidb-server tikv 日志也没有发现啥有用的报错信息。

备份使用的是/data/local_backup 目录虽然目录卸载了但相关的文件句柄是不是一直还在系统里占用着, 把 tikv 节点重启一下是否可以。

tidb 是三副本, 所以理论上关闭一个节点对业务上无影响。

Tiup

tiup pingcap 公司专门为 tidb 开发的管理工具。

因 tuip 需要管理多个集群, 为防止某台管理机宕机不可管理 ; 因此将 tuip 的相关信息存储在 ceph 上, 当前 ceph 不可用 tuip 也无法, 因此只能退回手动管理。

手动关闭 tikv 节点:

sudo systemctl stop tikv-20161.service

启动:

sudo systemctl start tikv-20161.service

启动报错:

[2020/10/20 11:17:46.389 +08:00] [FATAL] [server.rs:345] ["failed to create raft engine: RocksDb IO error: While lock file: /data/tidb-data/tikv-20161/raft/LOCK: Resource temporarily unavailable"]

初步怀疑 tivk 有一个文件锁, 非正常关闭不会删除文件锁。mv LOCK LOCK_back 在次启动还是同样报错。

再次猜测

有可能是机器上的文件句柄资源使用完了, 查看文件句柄配置文件

cat /etc/security/limits.conf

*     soft     nofile     655350*     hard     nofile     655350*     soft     nproc     655350*     hard     nproc     655350

文件句柄非系统默认

查看本机当前文件句柄数量

lost |wc -l 直接卡死

在一台非 tidb 机器执行看一下，非 tidb 机器执行速度很快 。更加确认是文件句柄的问题

lsof > /data/lsof.out

经过漫长的等待⌛终于完成了。

wc -l lsof.out 5668031 lsof.out

看看都是那些进程占用了

awk '{print $2}' lsof.out | sort | uniq -c|sort -n2716581 3690012919707 369003

解决问题思路

• 先关闭一台 tikv 上所有 tikv 节点

• 查看文件句柄数据量

• 重启 tikv 节点

• 观察日志

开始解决问题

关闭 Tikv 节点

sudo systemctl stop tikv-20161.service

sudo systemctl start tikv-20161.service

启动后日志没有滚动, 端口、进程, 都没有

查看 tikv-20161.service

cat /etc/systemd/system/tikv-20161.service

[Unit]Description=tikv serviceAfter=syslog.target network.target remote-fs.target nss-lookup.target
[Service]LimitNOFILE=1000000#LimitCORE=infinityLimitSTACK=10485760
User=tidbExecStart=/data/tidb-deploy/tikv-20161/scripts/run_tikv.shRestart=always
RestartSec=15s
[Install]WantedBy=multi-user.target

手动拉取run_tikv.sh 这个配置文件是否可行

nohup run_tikv.sh &

手动也无法拉起，端口进程, 日志没有打印

sh -x 查看脚本卡在了那里

cat run_tikv.sh

#!/bin/bashset -e
# WARNING: This file was auto-generated. Do not edit!#          All your edit might be overwritten!cd "/data/tidb-deploy/tikv-20161" || exit 1
echo -n 'sync ... 'stat=$(time sync || sync)echo okecho $statexec bin/tikv-server \"    --addr "0.0.0.0:20161" \"    --advertise-addr "10.92.xxx.xxx:20161" \"    --status-addr "10.92.xxx.xxx:20181" \"    --pd "10.92.xxx.xxx:2379,10.93.xxx.xxx:2379,10.94.xxx.xxx:2379" \"    --data-dir "/data/tidb-xxx/tikv-20161" \"    --config conf/tikv.toml \"    --log-file "/data/tidb-xxx/tikv-20161/log/tikv.log" 2>> "/data/tidb-xxx/tikv-20161/log/tikv_stderr.log"

sync 卡住了

使用命令重启试一下:

 /data/tidb-deploy/tikv-20161/bin/tikv-server \"    --addr "0.0.0.0:20161" \"    --advertise-addr "10.92.xxx.xxx:20161" \"    --status-addr "10.92.xxx.xxx:20181" \"    --pd "10.92.xxx.xxx:2379,10.92.xxx.xxx:2379,10.92.xxx.xx:2379" \"    --data-dir "/data/tidb-data/tikv-20161" \"    --config /data/tidb-xxx/tikv-20161/conf/tikv.toml \"    --log-file "/data/tidb-xxx/tikv-20161/log/tikv.log"

[2020/10/20 16:02:45.939 +08:00] [FATAL] [server.rs:295] ["lock /data/xxxx/tikv-20160 failed, maybe another instance is using this directory."]

/data/xxxx/tikv-20160 可能被某些文件正在占用

僵尸进程占用着文件

kill -s SIGCHLD pid

kill掉僵尸进程之后在次使用命令启动

僵尸进程: 僵尸进程占用着文件无法重启, 处理僵尸进程有两种方法一种是重启操作系统, 另一种杀死kill -s SIGCHLD pid 但也有可能杀死父进程的 pid 变为1 此时就无法kill只能重启操作系统。

命令重启后，日志滚动看着日志是正常 tikv 打印，注释掉脚本里相关sync 然后在启动

#!/bin/bashset -e
# WARNING: This file was auto-generated. Do not edit!#          All your edit might be overwritten!cd "/data/tidb-deploy/tikv-20161" || exit 1
#echo -n 'sync ... '#stat=$(time sync || sync)#echo ok#echo $statexec bin/tikv-server \"    --addr "0.0.0.0:20161" \"    --advertise-addr "10.92.xxx.xxx:20161" \"    --status-addr "10.92.xxx.xxx:20181" \"    --pd "10.92.xxx.xxx:2379,10.92.xxx.xx:2379,10.92.xxx.xx:2379" \"    --data-dir "/data/tidb-data/tikv-20161" \"    --config conf/tikv.toml \"    --log-file "/data/tidb-deploy/tikv-20161/log/tikv.log" 2>> "/data/tidb-deploy/tikv-20161/log/tikv_stderr.log"

sudo systemctl daemon-reload 重新加载tikv-20161.service

sudo systemctl start tikv-20161.service

• 为了后面还可以使用 tiup 进行管理, 还是使用systemctl 进行启动

tikv 可以正常启动, 但这样做非常不友好，当前正在这个 store 上的业务业务上会受影响。

因此我们需要在启动某个节点的时候把该节点上的 region 进行驱逐

调度 region

./pd-ctl -u http://10.92.xxx.xxx:2379

查看当前所有的 tikv 节点:

>>store

把 store 1 上的所有 Region 的 leader 从 store 1 调度出去

scheduler add evict-leader-scheduler 1

把对应的 scheduler 删掉, 如果不删除 store 1 节点不然再被调度 region

scheduler remove evict-leader-scheduler-1

业务恢复正常

重启完所有 tikv 节点后业务恢复正常

其它问题

• 理论上 15 个节点 关闭 3 个节点 不会影响正常的请求 当时的表现是关闭 3 个节点 直接就无法访问了noleder
  

官方回复:

由于 grpc 线程卡死，tikv 向 pd 上报的 heardbeat 失败，pd 此时已有一个 region 迁移的操作，但是只成功了添加 learner 的操作，后 pd 检查到现在有四个 peer，一个 learner，一个挂掉的，两个正常的，就把挂掉的干掉了 。此操作属于 PD 的预期行为，正在讨论是否需要进行改进

• Tikv 发现资源可用为啥一直建立这么文件句柄

官方回复:

lsof 看起来会把 threads 所能访问到的所有 fd 都打出来，也就是说这里 grep 出来的数量 / 线程数 才是真实的 fd 数量

• 10.20 日 Ceph 卡死时 BR 备份导致集群 QPS 掉底问题

官方回复:

BR 发起备份时，tikv 向 ceph 盘创建目录，导致 tikv grpc 卡主，最终导致 TiKV 无响应 QPS 掉底。通过 PD 日志判断，也符合此推断此问题 4.0.8 版本修复

• 如果改用 ceph s3 API 是否会存在风险

官方回复:

建议继续使用 local 模式备份

ceph s3 协议未进行充分测试

目前官方在 4.0.8 版本当中修复此问题: issue:https://github.com/tikv/tikv/pull/8891

期待

 希望官方对ceph s3 协议纳入测试体系

感谢

最后感谢官方在解决问题的过程提供的远程支持。再次感谢！