现象

在我一次对数据库sysbench压测的时候，对数据库准备压测的数据时，居然报[9005]; Region is unavailable

以下是sysbench的config文件

mysql-host=10.11.142.246
mysql-port=3806
mysql-user=root
mysql-password=1111
mysql-db=sbtest
time=120
threads=300
report-interval=10
db-driver=mysql

以下是sysbench准备数据的命令，大概是准备16张表，每张表数据量1000W.

/usr/local/sysbench/bin/sysbench --config-file=config oltp_point_select --tables=16 --table-size=10000000 prepare

分析原因

参照官方文档的集群问题导图对Region is Unavailable的问题导图进行了核查

https://docs.pingcap.com/zh/TiDB/v6.5/tidb-troubleshooting-map#11-%E5%AE%A2%E6%88%B7%E7%AB%AF%E6%8A%A5-region-is-unavailable-%E9%94%99%E8%AF%AF

首先在tikv的日志中发现如下报错

和

在tidb中发下如下报错：

基本可以确定时第一种情况或者第五种情况。

第一种情况主要时tidb在往tikv上面并发写入大量数据时，因为tikv 因为资源紧张导致not leader或者epoch not match 原因被打回；又或者请求 TiKV 超时等），TiDB 内部会进行 backoff 重试。backoff 的时间超过一定阈值（默认 20s）后就会报错给客户端。

但是查看grafana的监控，tikv节点在对应时间段的cpu、内存和io以及网络都不算特别忙碌

tidb-smk-overview→system info

tidb-smk-tikv-details→cluster

这是怀疑是第五种情况，同时参照了case-958，查看了grafana对应的监控

tidb-smk-tikv-details→Raft IO→apply log duration

和tidb-smk-tikv-details→Raft propose→apply wait duration

发现apply log duration并不高，但是apply wait duration非常高，这时结合tidb集群问题导图中的tikv写入慢中apply慢的问题诊断步骤

https://docs.pingcap.com/zh/tidb/v6.5/tidb-troubleshooting-map#45-tikv-%E5%86%99%E5%85%A5%E6%85%A2

查看grafana中对应监控

tidb-smk-tikv-details→Thread CPU→asyncapply cpu

发现apply线程的cpu使用程度已经达到了惊人的196%，而默认的apply-pool-size参数就是2，这也就意味着apply线程已经是在满负荷运行了，看了必须要调整apply-pool-size参数了

处理方法

通过在线修改tikv的apply-pool-size参数为4，即apply线程默认最多使用4颗cpu

SHOW config WHERE NAME LIKE '%apply-pool-size%';
SET config tikv raftstore.apply-pool-size='4';

最终效果

重新生成数据库准备压测的数据，不再报[9005]; Region is unavailable错，同时监控apply进程相关的grafana监控

tidb-smk-tikv-details→Thread CPU→asyncapply cpu

tidb-smk-tikv-details→Raft IO→apply log duration

和tidb-smk-tikv-details→Raft propose→apply wait duration

发现apply线程的cpu使用程度最多也只到376%，没有到极限，apply log duration并不高，但是apply wait duration还是有点高，但是相对于apply-pool-size='2'时，已经降低了很多了。

总结

基本官方文档里面的集群问题导图，进行分析，一般问题都能解决，排查问题要细心。https://docs.pingcap.com/zh/tidb/v6.5/tidb-troubleshooting-map#tidb-%E9%9B%86%E7%BE%A4%E9%97%AE%E9%A2%98%E5%AF%BC%E5%9B%BE

另外考虑此次异常的底层原因，由于原来在一个三台16C64G的云主机搭配垃圾存储的部署的集群也做过类似的数据生成，但是并没有报错，这次反而是在一个三台32C128G的物理机搭配ssd存储的部署的集群出现了问题，感觉是tikv的apply-pool-size参数的默认值2在应对高速磁盘写入时无法受限于apply线程的cpu无法及时的进行apply log，故导致此故障，所以如果使用的磁盘io性能更好时，应该适当的调大此值。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。