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. 热点打散

TiDB学习笔记(八)-数据库故障处理_第1张图片

 TiDB学习笔记(八)-数据库故障处理_第2张图片

 (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)调度的控制-产生速度控制

TiDB学习笔记(八)-数据库故障处理_第3张图片

 (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节点下线速度慢-解决方案

TiDB学习笔记(八)-数据库故障处理_第4张图片

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

TiDB学习笔记(八)-数据库故障处理_第5张图片

region merge速度慢-解决方案TiDB学习笔记(八)-数据库故障处理_第6张图片

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

TiDB写入流程

TiDB学习笔记(八)-数据库故障处理_第7张图片

 (1)排查思路

        1.典型问题

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

        2.复杂问题

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

七、TiDB数据库读取慢

排查思路:

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

TiDB学习笔记(八)-数据库故障处理_第8张图片

 

 

你可能感兴趣的:(TiDB,数据库,tidb,java)