一、数据丢失快速恢复
数据恢复前置条件-GC,tidb_gc_life_time
查询GC已经清理的时间点tikv_gc_safe_point
数据快速恢复操作方式
DML->tidb_snapshot参数 (在tikv_gc_safe_point范围内)
DDL->flashback table/recover table (flashback table适用drop、truncate,recover table适用drop要在tidb_gc_life_time 时间范围内)
DDL+DML ->dumpling工具
二、TiDB OOM问题
诊断方法
- 客户端报错 lost connection to Mysql server during query
-
dmesg -T |grep tidb-server
tidb.log tidb发生重启
tidb_stderr.log
-
grafana tidb->server->memory usage 内存迅速升高,又迅速下降
tidb->server->uptime tidb的启动时间
OOM产生的原因
OOM产生的原因
- SQL语句的执行
- golang内存释放机制
定位内存占用大的SQL
- TiDB Dashboard 慢查询
- TiDB Dashboard SQL语句分析
- TiDB Server 日志中的expensive query(可记录正在执行的SQL)
缓解OOM的措施
- SQL优化,减少非必要返回的数据量
- 减少大事务,将大事务拆分为小事务
- 调整相关参数,限制单条SQL的内存使用量(mem-quota-query,达到内存限制后,如果也没有临时磁盘可用,将触发oom-action) 启用临时磁盘 oom-use-tmp-storage,tmp-storage-path,tmp-storage-quota
- 其他缓解OOM的方法 go运行时释放内存的两种策略MADV_DONTNEED(不用的内存快速回收),MADV_FREE(内存快耗尽时才开始回收),tidb启动前设置GODEBUG=madvdotneed=1。滚动重启tidb server
三、TiKV OOM问题
对业务影响
- TiKV请求失败造成异常退出
- region leader重新选举。raft group开始重新选举region leader,新的region leader上报给PD
- region cache频繁更新。在访问TiDB的region cache时,出现TiKV rpc相关报错;后台自动进行backoff重试;PD将最新的region leader信息返回给TiDB的region cache
诊断方法
- dmesg -T|grep tikv-server; Tikv.log中查找
- grafana监控 tikv->details->cluster->memory
OOM产生的原因
- block cache设置不当(grafana tikv-details->rocksdb KV->block cache size,参数设置storage.block-cache.capacity 不超过总内存的60%,可在线调整)
- Coprocessor收到大量查询,返回数据量太大,gRPC的发送速度跟不上Coprocessor往外输出数据的速度(grafana tikv-details->coprocessor overview->total response size,node_expoter->network->network in/out traffic,对比两个流量的大小。)解决办法:SQL优化;网卡配置升级
- 其他进程占用太多内存。raftstore数据写入环节内存占用高;目标服务器混布其他组件且内存占用高
四、数据库热点问题
(1)形成写热点的原因-数据组织模型
(2)形成读热点的原因
- 高频访问小表
- SQL执行计划不合理
- 具有顺序增长属性的索引扫描
(3)定位热点
1.TiDB Dashborad
- 流量可视化页面
- 慢查询页面
- SQL语句分析
2.grafana
- TiKV-Trouble-Shooting
- TiKV-Details
- PD
(4)写热点打散
- 表结构 shard_row_id_bits和pre_split_regions
- auto_random 主键非空且唯一,打散主键的顺序
- 索引 split table table_name index idx_name between () and () regions n
- 系统变量 tidb_scatter_region,作用域global 默认OFF
(5)写热点排查流程
- TiDB Dashboard流量可视化页面,观察写流量情况
- TiDB Dashboard 慢查询 & SQL语句分析,确认对应数据库对象的DML操作类型
- 查看目标对象schema信息
- 热点打散
(6)读热点打散
- TiDB Dashboard 流量可视化页面观测读流量的情况
- TiDB Dashboard 慢查询&SQL语句分析,确认问题时间段数据库中SQL的执行频次、扫描数据的行数
小表频繁访问引起热点,两种打散方式
- set config tikv split.qps-threshold=3000; set config tikv split.byte-threshold = 30
- curl -X POST ........split.qps-threshold、split.byte-threshold
SQL执行计划不合理
- 缺少索引
- 多个索引,但优化器选择错误
五、PD调度常见问题
(1)常见调度类型
- Balance
- leader
- region
- Hot region
- 写热点
- 读热点
- 集群拓扑
- Region merge
(2)调度的控制-产生速度控制
(3)PD调度场景
- Leader/Region分布不均衡
- TiKV节点下线速度慢 grafana PD ->statistics-balance->Store leader count&Store region count
- TiKV节点上线速度慢 grafana PD ->statistics-balance->Store leader count&Store region count (参考Leader/Region分布不均衡的解决方案)
- 热点region分布不均衡 grafana PD->statistics->hot write
- region merge速度慢 grafana PD->region health
Leader/Region分布不均衡-解决方案
TiKV节点下线速度慢-解决方案
热点region分布不均衡-解决方案
region merge速度慢-解决方案
六、TiDB写入慢常见处理方式
TiDB写入流程
(1)排查思路
1.典型问题
- 物理环境导致写入慢
- 业务变更
- 慢查询语句
- 写入热点问题
2.复杂问题
- 对照TiDB写入流程进行排查
七、TiDB数据库读取慢
排查思路:
- 集群整体响应变慢,确认问题组件tidb、tikv或PD
- 某个SQL响应变慢
- slow query定位持续出现的慢查询
- tidb dashboard 慢查询定位目标慢SQL