Snapshot 模块
无论是走 Storage read pool 还是 Coprocessor pool 两个线程池,在处理请求之前都需要先构建一个 Snapshot,我们后续的读都是基于这个 Snapshot 的,这也是为什么 TiDB 的隔离级别叫 Snapshot 隔离级别的一个原因。
通常获取 Snapshot 很快,但会有一些场景影响 Snapshot 获取时间:
-
当 TiKV 写压力非常大时,这是由于目前没有单独获取 snapshot 的线程,可能会导致获取 Snapshot 时间延长(此处可以参考 TIKV 写流程)。
-
当读请求走的是 index read 时,因网络不好也会影响获取 snapshot 的时间(这是因为 TIDB 的分布式存储方式,数据与索引可能并没有存储在一个 TiKV 实例中)
-
没有使用到 Local Read
- 扩展知识点 Local Read 。简单讲为了保证数据的读一致性,我们的读都是从 Region Leader 上进行读取的,如果读请求发送到了 TiKV 节点正好是此 Region 的 Leader 节点,那么我们就是用 local read,减少额外的开销
-
Snapshot 的监控
- TiKV-Detail → Storage → storage async snapshot duration 查看,如果该值较高,需要判断 raft store 是否繁忙,并查看是不是很多查询,没有走 local read,并且查看当前的网路状况是否良好。
- local read 的监控可以在 TiKV-Detail → Local read 查看,里面记录各种 local read 的数量。
- TiKV-Detail → Storage → storage async snapshot duration 查看,如果该值较高,需要判断 raft store 是否繁忙,并查看是不是很多查询,没有走 local read,并且查看当前的网路状况是否良好。