1.背景

最近处理了一起由于 *** 磁盘寿命耗尽导致的 TiDB 集群写入变慢的问题，集群部署组件如下表所示，服务器磁盘是 SATA ***、RAID 10。

模块名称版本信息数量tidbv4.0.95pdv4.0.93tikvv4.0.911pumpv4.0.95drainerv4.0.91tiflashv4.0.92

2.问题描述

2022 年 5 月 18 号 23:09 左右，收到大量 TiDB 告警，部分告警信息如下，DBA 立刻开始排查分析，本文内容中涉及到的 IP 已脱敏。

TiKV scheduler command duration seconds more than xs TiKV scheduler latch wait duration seconds more than xs TiKV scheduler latch wait duration seconds more than xs

3.问题分析和解决

先看下集群整体响应时间：SQL 99 开始升高，平时 SQL 99 在 125ms 左右，报警时 SQL 99 已经上升到 2s 左右，升高好几倍(下图中间隔部分忽略，同事误重启集群监控导致的，不是重启的集群)。

看了下 show processlist ，发现大部分 SQL 都变慢了。看看集群整体负载情况(Overview --- System Info )，发现一台服务器的 IO Util 达到了 100%，下图中 TOP 2 的 sda 和 sdb 位于同一台服务器上。

然后看了下 raft store cpu 和 Unified read pool CPU，未发现明显异常。接下来，看看这台服务器的磁盘详细监控情况，是否有什么异常。

不看不知道，一看吓一跳。从上图可以看到，又出现了之前曾经遇到过的诡异问题：iops 突然降低，写入延迟反而升高。只是这次不同的是，iops 几乎跌为 0 了，而写入延迟却高达 400ms 以上，峰值高达 15.87 秒，这台服务器上部署了 2 个 TiKV 实例，分别在 sda 和 sdb 上。同时查看了其他 TiKV 服务器的磁盘 iops 和写入延迟，均未发现异常：写入延迟在 us 级别，但是 iops 也降低到 1000 左右。

为了尽快恢复集群，这次又尝试使用驱逐这台服务器上 TiKV 的 region leader 的方式，命令如下：

scheduler add evict-leader-scheduler 4 # 问题服务器 TiKV1,位于 sda scheduler add evict-leader-scheduler 9 # 问题服务器 TiKV2,位于 sdb

执行完上述命令一段时间后，集群依然没有恢复正常，看来经常用的这个命令这次失效了。在这期间登录到服务器上查看系统日志未发现异常日志。于是，尝试将这台服务器重启，执行完 reboot 几分钟之后，集群竟然恢复了。当服务器启动之后，守护进程将之上的 TiKV 进程拉了起来，此时集群写入又开始变慢，看来重启服务器也没什么用。既然停掉服务器，集群可以恢复正常，启动服务器，集群写入又开始变慢，如果服务器硬件有问题，重启服务器是无法解决问题的。那直接停掉 IO 最高的这块盘上的 TiKV 集群是否可以恢复呢，尝试停掉 IO 最高的磁盘上的 TiKV 后，集群恢复了正常（后续缩容掉了这个 TiKV 实例）。 虽然问题解决了，但是什么原因导致的这台服务器 IO 写入突然延时这么高呢？是 RAID 卡放电造成的？还是硬件故障造成的？还是其它原因？

分析服务器 RAID 卡日志，未发现充放电现象；分析 dmesg 日志，也未发现异常。

尝试登录服务器 idrac 寻找答案，查看各硬件信息和硬件日志是否有异常，在看磁盘信息时看到有几块磁盘的寿命竟然快到 0% 了，几乎耗尽，而这几块盘正好组成了 sdb 。

到这里，我们已经知道原因了：192.168.1.1 这台服务器磁盘寿命耗尽导致的 IO 写入变慢（IO几乎不可用），进而导致这台服务器上的 TiKV 写入几乎停滞，最终影响了整个集群，出现了开头一幕，写入变慢的现象。

回过头来再看报警信息，发现报警信息基本上全部来自于 192.168.1.1 这台出问题的服务器，所以也可以按照这个信息去首先分析这台服务器是否出现异常，可能更节省时间。

4.*** 寿命简介

本节部分内容来自于网络，简单讲述下 *** 的寿命相关内容。

什么是 *** 的寿命 通常说的 *** 寿命是指在 *** 生命周期内允许的数据写入量。

如何计算 *** 寿命 ***寿命单位有两种，PBW（或TBW）和 DWPD：

(1) PBW（或TBW）：全称Petabytes Written（或Terabytes Written），在***的生命周期内允许的主机端数据写入量。1PBW = 1000TBW

(2) DWPD：全称Drive Writes Per Day，在***的生命周期内，每天允许全盘写入的次数。

DWPD和PBW/TBW可以相互换算，公式如下：

TBW：Total Bytes Written 或者 Tera Bytes Written的缩写，但两种解释都是同一个意思：总写入数据量。

例如本文中提到的问题服务器的磁盘的耐用等级(终身写入)是 1.2 PBW，保修期 5 年 ，那么 日均写入量 = TBW  * 1000 / 质保天数，即

657.5G = 1200 * 1000 / 365 * 5

在 5 年质保年限内需要每天都写入 657.5G 的新数据，才会把 TBW 写满

如何检测 *** 的寿命 厂家会提供相关工具，这里以戴尔服务器为例：可以登录 idrac web 页面查看，如本文上面截图。或者安装厂家提供的 racadm 软件，安装后使用命令行检测硬盘寿命相关信息。

这里提一下，TiDB 集群本身也提供磁盘写入延迟的报警，出问题期间，也收到过类似报警，这个报警指标还是很重要的。 disk_write_latency_more_than_16ms->状态: 问题 cluster: xxx_cluster, instance: 192.168.1.1:9100, values: 1019.0510725229362 1019.0510725229362

5.总结

本文简单描述了一次 *** 寿命耗尽导致的 TiDB 集群写入变慢问题的现象、分析和解决过程。

一是业务写入非常频繁，二是 TiDB 自身在不停的调度，均衡，所以对磁盘的消耗还是比较大的。因此，建议大家平时做好服务器磁盘寿命的监控，当低于指定阈值时及时报警，避免出问题时对集群造成影响，也可以预防同一批次的 *** 同时大规模损坏，造成严重后果。

【参考文章】

https://mp.weixin.qq.com/s/Y30cyrQ8U7wRy3I1zZL3Fw

https://zhuanlan.zhihu.com/p/383223146

https://www.intel.cn/content/www/cn/zh/products/sku/134920/intel-ssd-d3s4510-series-480gb-2-5in-sata-6gbs-3d2-tlc/specifications.html