TiDB学习笔记（八）-数据库故障处理

一、数据丢失快速恢复

数据恢复前置条件-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问题

诊断方法

1. 客户端报错 lost connection to Mysql server during query

2. dmesg -T |grep tidb-server

   tidb.log  tidb发生重启

   tidb_stderr.log

3. grafana tidb->server->memory usage   内存迅速升高，又迅速下降

   tidb->server->uptime tidb的启动时间

   OOM产生的原因

OOM产生的原因

1. SQL语句的执行
2. golang内存释放机制

定位内存占用大的SQL

1. TiDB Dashboard 慢查询
2. TiDB Dashboard SQL语句分析
3. TiDB Server 日志中的expensive query（可记录正在执行的SQL）

缓解OOM的措施

1. SQL优化，减少非必要返回的数据量
2. 减少大事务，将大事务拆分为小事务
3. 调整相关参数，限制单条SQL的内存使用量（mem-quota-query,达到内存限制后，如果也没有临时磁盘可用，将触发oom-action）  启用临时磁盘 oom-use-tmp-storage,tmp-storage-path,tmp-storage-quota
4. 其他缓解OOM的方法   go运行时释放内存的两种策略MADV_DONTNEED(不用的内存快速回收),MADV_FREE（内存快耗尽时才开始回收），tidb启动前设置GODEBUG=madvdotneed=1。滚动重启tidb server

三、TiKV OOM问题

对业务影响

1. TiKV请求失败造成异常退出
2. region leader重新选举。raft group开始重新选举region leader，新的region leader上报给PD
3. region cache频繁更新。在访问TiDB的region cache时，出现TiKV rpc相关报错；后台自动进行backoff重试；PD将最新的region leader信息返回给TiDB的region cache

诊断方法

1. dmesg -T|grep tikv-server;  Tikv.log中查找
2. grafana监控 tikv->details->cluster->memory

OOM产生的原因

1. block cache设置不当（grafana tikv-details->rocksdb KV->block cache size,参数设置storage.block-cache.capacity 不超过总内存的60%，可在线调整）
2. Coprocessor收到大量查询，返回数据量太大，gRPC的发送速度跟不上Coprocessor往外输出数据的速度（grafana tikv-details->coprocessor overview->total response size,node_expoter->network->network in/out traffic,对比两个流量的大小。）解决办法：SQL优化；网卡配置升级
3. 其他进程占用太多内存。raftstore数据写入环节内存占用高；目标服务器混布其他组件且内存占用高

四、数据库热点问题

（1）形成写热点的原因-数据组织模型

（2）形成读热点的原因

1. 高频访问小表
2. SQL执行计划不合理
3. 具有顺序增长属性的索引扫描

（3）定位热点

1.TiDB Dashborad

• 流量可视化页面
• 慢查询页面
• SQL语句分析

2.grafana

• TiKV-Trouble-Shooting
• TiKV-Details
• PD

（4）写热点打散

1. 表结构 shard_row_id_bits和pre_split_regions
2. auto_random 主键非空且唯一，打散主键的顺序
3. 索引 split table table_name index idx_name between () and () regions n
4. 系统变量 tidb_scatter_region，作用域global 默认OFF

（5）写热点排查流程

1. TiDB Dashboard流量可视化页面，观察写流量情况
2. TiDB Dashboard 慢查询 & SQL语句分析，确认对应数据库对象的DML操作类型
3. 查看目标对象schema信息
4. 热点打散

 

 （6）读热点打散

1. TiDB Dashboard 流量可视化页面观测读流量的情况
2. TiDB Dashboard 慢查询&SQL语句分析，确认问题时间段数据库中SQL的执行频次、扫描数据的行数

        小表频繁访问引起热点，两种打散方式

1. set config tikv split.qps-threshold=3000;   set config tikv split.byte-threshold = 30
2. curl -X POST ........split.qps-threshold、split.byte-threshold

        SQL执行计划不合理

1. 缺少索引
2. 多个索引，但优化器选择错误

五、PD调度常见问题

（1）常见调度类型

1. Balance
   1. leader
   2. region
2. Hot region
   1. 写热点
   2. 读热点
3. 集群拓扑
4. Region merge

（2）调度的控制-产生速度控制

 （3）PD调度场景

1. Leader/Region分布不均衡
2. TiKV节点下线速度慢  grafana PD ->statistics-balance->Store leader count&Store region count
3. TiKV节点上线速度慢 grafana PD ->statistics-balance->Store leader count&Store region count  （参考Leader/Region分布不均衡的解决方案）
4. 热点region分布不均衡 grafana PD->statistics->hot write
5. region merge速度慢 grafana PD->region health

Leader/Region分布不均衡-解决方案

TiKV节点下线速度慢-解决方案

热点region分布不均衡-解决方案

region merge速度慢-解决方案

六、TiDB写入慢常见处理方式

TiDB写入流程

 （1）排查思路

        1.典型问题

• 物理环境导致写入慢
• 业务变更
• 慢查询语句
• 写入热点问题

        2.复杂问题

• 对照TiDB写入流程进行排查

七、TiDB数据库读取慢

排查思路：

1. 集群整体响应变慢，确认问题组件tidb、tikv或PD
2. 某个SQL响应变慢
   1. slow query定位持续出现的慢查询
   2. tidb dashboard 慢查询定位目标慢SQL