tikv_storage_async_request指标统计结果分析

[HoniiTro19]

【 TiDB 版本】v6.0.0
【 集群参数 】

# 关闭集群的热点调度和region的split
tiup ctl:v6.0.0 pd config set leader-schedule-limit 0
tiup ctl:v6.0.0 pd config set region-schedule-limit 0
tiup ctl:v6.0.0 pd config set hot-region-schedule-limit 0
tiup ctl:v6.0.0 pd config set hot-region-cache-hits-threshold 60
tiup ctl:v6.0.0 pd config set replica-schedule-limit 0
tiup ctl:v6.0.0 pd config set merge-schedule-limit 0
set config tikv split.qps-threshold=1000000;
set config tikv split.byte-threshold=10000000;

【遇到的问题】
在跑高冲突的实验时，对单行数据进行select for update，所有query落在同一个region，观察tidb dashboard的统计结果，可以看到region leader所在节点（10.24.14.22）的tikv_storage_async_request请求数量很高。
我的疑问是为什么其他节点也有write和snapshot的请求？

[xiaohetao (Becky)]

一般情况 是优先找leader 角色的,

如果leader 较忙的时候 follower 会处理一部分读取请求， 但是 这取决于 tidb_replica_read 参数， 看看你集群中tidb_replica_read 是如何配置的。

https://docs.pingcap.com/zh/tidb/dev/follower-read#follower-read

[HoniiTro19]

@xiaohetao

tidb_replica_read

您好，集群中tidb_replica_read设置为leader，并且我的负载全部都是select for update + update，我觉得不会将请求发送给follower节点。

[h5n1]

数据库内就算没有业务也会有一些内部活动的。更新数据 执行sql时会涉及统计信息更新 加载等，比如stats_meta 可以看下sql分析中除业务sql外的其他sql

[xiaohetao (Becky)]

配置的是leader, 那 follower 节点的 write 应该 raft log 及写入和集群内部调度有关