TiDB schema error告警

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

  • 【TiDB 版本】:V4.0.4
  • 【问题描述】:TIDB集群最近0:00-1:00,每天都会存在TiDB schema error告警,还请帮忙看看TIDB服务不可用的原因,谢谢。

告警
image
image
同步任务告警:
image

TIDB\TIKV\OVERVIEW截图如下:
链接:https://pan.baidu.com/s/1lvUa9EJBslvxwpE2v1c5ww
提取码:a015

TiDB schema error 表示 TiDB 在一个 Lease 时间内没有重载到最新的 Schema 信息,通常是由于 TiKV 不可用或负载过高导致

从 TiKV 监控,告警期间各 TiKV 的 IO Util 100%,并且 rocksdb 写入延迟过高,影响了 raft 日志刷盘,导致 grpc 请求超时


可以先查一下每天这个告警时间段的业务行为,比如是否批量读写等导致的 IO 瓶颈

一、业务行为主要有2类:
1、数据同步,通过sqoop把hive的数据抽取到tidb:在这个时间点,有3张表的同步,表数据都不大,如下:


对于后两张表,同步频率都是2小时同步一次,但一直都是在0点的同步会失败:如下

2、DM实时数据同步,从上游mysql同步到tidb,刚看了所有worker的binlog文件,在这个时间段,binlog日志文件很少,每个worker下都只有几个binlog。

分析以上2个业务场景,应该可以确定不是这两个场景影响了tidb的性能。

二、对于磁盘io的问题,之前也查过只要有大批量的入库,监控都会有这种现象。看3点-4点,有千万级别的表数据同步,io也是接近100%,但也没有TIDB schema error的告警。

监控上 1~2 点的日志刷盘延迟抖动要比 3~4 点更高一些,高水位持续时间也较长

可以再找下 Disk Performance 的监控,对比这两个时间段的磁盘监控,如 disk latency (write latency 需要 edit 进去点掉隐藏的 metric)/ disk bandwidth / disk operation(iops) / disk load / io util 等 metric,关注下读写吞吐量和 iops,那段时间是否有吞吐量或 iops 达到瓶颈

如果确认是 1~2点 的 io 负载更高,那很可能还是跟 io 有关,有现场可以抓 iotop 看看具体是哪些线程消耗 io,是否 tikv 或者其他进程的线程

以这个tikv节点为例子,看监控,0~1点之间的各项指标,出了磁盘io比较高外,其他指标看起来都是比较低的。

1~2 点 ioutil 100% 这段时间 iops 和吞吐量基本上没有流量,其他几个 tikv 节点也有类似现象吗,可能需要进一步现场 iotop 来查看是哪个进程占用 io,之前遇到过一些文件系统的 jbd2 线程引起磁盘 io 高的 case

TIKV三台服务器所在IO都非常高,特别是jbd2/vdb1-8,IO占用50%以上。

隐藏esc坑之jbd2进程io占用奇高 系统长期io占用100%

tidb 4.0-rc tikv 节点的数据盘 IO 使用率 100%

再看下 tikv 的 node_exporter 系统监控,那段时间有没有异常,可以将 grafana 监控导出 json 文件上传,参考 [FAQ] Grafana Metrics 页面的导出和导入

json文件如附件

Tidb-Cluster-Node_exporter_2020-10-13T06_19_48.967Z.json (134.2 KB)

其他tikv节点都是一样的现象。
今晚0点之后我再确认是哪些进程占用了io。

json 里面没有数据,是不是导出的时候 grafana 页面还没加载完成

Tidb-Cluster-Node_exporter_2020-10-13T09_08_01.300Z.json (2.8 MB)

麻烦重新看看行不行


这段时间 disk write latency 不太正常,sda 和 vda 都受影响,可能什么操作导致 io 卡了

过了几个月了,来写一下问题的结论:
1、前期和戚铮老师现场抓iotop确认是jdb2进程占用了大量的io,在受影响时间点TIDB并没有什么大量的读写操作,所以怀疑是磁盘本身存在问题。
2、由于集群是部署在虚拟机的,和dba聊起这个问题,他们反馈mysql集群在凌晨也有磁盘IO满的情况,并且已经确认了是物理机集群所在的其他组件的定时任务影响了mysql的磁盘io,所以我们对于tidb的问题,更坚信是相同的情况
3、配置/bin/dstat -tclmsdrgny 1 58 抓取tidb集群所有主机的磁盘io情况,读写很小,但iowait特别大,并反馈给基础架构同事,让他们确认那个时间点虚拟机所在物理机磁盘情况


4、后续结果和预料的是一致的,在凌晨10分左右,有mysql定时备份任务,该任务跑的时候会吃光交换机到盘阵之间的网络带宽,导致tidb服务不可用。后续把定时任务迁移走并进行限速解决。

结论:虚拟机部署的集群,tidb没有读写的情况下,磁盘io过大(jdb2占了大部分)的情况下,可以考虑在同一个物理机的集群中,是否有其他应用影响了tidb性能

1赞

学习学习