导读
作者:杨漆
16年关系型数据库管理,从oracle 9i 、10g、11g、12c到Mysql5.5、5.6、5.7、8.0 到TiDB获得3个OCP、2个OCM;运维路上不平坦,跌过不少坑、熬过许多夜。把工作笔记整理出来分享给大伙儿,希望帮到大家少走弯路、少熬夜。
- 当Sql进入TiDB时先获取Token,事务开始时获取Start TS (异步方式获取)
- 由Parse解析为AST树进行预处理(当开启Prepared Statement并命中时会跳过前两步)、逻辑优化(当开启Prepared Plan Cache并命中时会跳过前三步)、物理优化
- 执行器根据Physical Plan 执行
- 事务结束获取Commit TS,并进行Commit
- 整个Sql运行结束
A. 在执行sql之前先获取Token 和Start TS ,Token用于限制sql的并发数,避免TiDB被资源耗尽而挂掉(如果获取Token耗时较高说明达到了Token上限,有sql排队等待)
B. 开始/提交事务都会向PD获取TSO,经历两个阶段:
I.Wait Duration (延迟大时说明TiDB的负载高)
II.RPC Duration (延迟大时说明TiDB和PD之间的传输耗时大,或PD的负载高) - parse的耗时(一般只有bash insert 时耗时高)、Compile的耗时(包括预处理和优化,一般在复杂查询时慢)从DashBoard对应面板可以看到
- 开启Prepared statements 提高parse和预处理的开销(通过prepare statement count可查看该功能是否生效)
- 开启Prepared Plan cache,节省optimizing开销(通过Plan Cache hits可查看该功能是否生效)
- Execution duration 查看整体执行阶段耗时
- Expensive execution查看复杂算子的OPS(可通过调整tidb_{operator}_concurrency来降低延迟)
- Tikv请求耗时、region error导致延时过高(一般由region cache过期导致)、锁冲突高导致
- DistSQL是TiDB 向Tikv发送请求、接收数据的接口
- DiskSQL Duration可以看出DiskSQL请求的延时(tidb_distsql_scan_concurrency控制并发度参数,当延迟大时可调节该参数来降低延迟)
- Scan Keys体现扫描的数据量,会影响延迟
- 事务在Tikv的耗时高主要体现在 Local Latch 和 事务重试
- Local Latch:Tidb在commit前对事务排序用的锁(默认为关闭),当锁冲突较多时可以打开。耗时情况在Dashboard的sql statement & slow queries 和Grafana的Local Latch Wait Time中可以监控到
- 事务重试只在一部分事务出现错误时进行尝试(如:写冲突),重试次数在Dashboard的sqlstatement & slow queries 和 Grafana的Transaction Retry Num中可以监控到
- Tikv通过gRPC接收到请求。
- 写请求通过scheduleràraftstoreàRocksDBraftàRocksDB kv阶段
- 读请求通过ReadpoolàRocksDB kv
- 在RocksDB中先会WAL,访问memtable,若没命中访问block cache,还没命中就访问SST
- gRPC上反映了TiKV请求的延迟,包括上图指标
- TiDB上的kv request延迟是gRPC+网络延迟的总和(若kv request与gRPC差异大,证明TiDB和Tikv之间的网络延迟大 )
重写和重解析锁在Dashboard中以上两个位置可看到
1. Raft store 发生在写流程中,用来把raft log同步到所有的副本
2. 提raft log( raft propose)
3. 写数据(Raft IO):append log 是写在日志末尾、apply log 是应用到数据库中、commit log 是提交日志
如果Coprocessor等待时间高可以打开coprocessor cache - 每个Tikv有两个RocksDB实例,分别用于存储raft日志和KV数据
- 读数据时先读Memtable,没有命中读block cache,再没命中读SST
- 写数据的相关 监控在write duration中查看
- RocksDB在后台做compaction (operations 代表次数,duration代表耗时)