作者： tidb菜鸟一只
现象
在我一次对数据库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性能更好时，应该适当的调大此值。
