tidb 10T大表空间自动回收致tidb hang住

[toc]

【 TiDB 使用环境】

版本:4.0.9
tidb+pd 共用
4台 4c 8G 300G SSD磁盘(4 tidb, 3 pd)
tikv
8台16c 64G SSD本地盘机器

【概述】

9.8号 22:36 有日志tidb集群tikv节点内存报警,进grafana监控中发现QPS都陡降(写入 读取请求量基本都降为0),持续实际15分钟左右


【背景】

没有做过操作,过15分钟左右自行恢复可用

【现象】

发现该时间段是在做空间回收,9.7号22:26做了清除(truncate xx_log 10T无用日志表)操作,truncate这日志表前10来分钟还下线过对这表的cdc同步,这表在上个月8月中旬就已经没有写数据了,业务应用方改成写分表了
image


数据写入没成功重试导致4 tidb计算节点连接数暴涨(40左右->2k左右)
image

8 tikv存储节点cpu利用率上涨了1倍多

有2 tikv节点leader 在出现减少情况

pd监控中看22:41空region数据涨到最对14.3W个(143000*96/1024/1024=13T,与24h前清除的表大小一致)

tikv节点io利用率上升

8 tikv存储节点 读吞吐100~250MB/s;写吞吐100~200MB/s
image

tidb 自身dashboard 热力图看对表有很大的写入量,没有读取量


【业务影响】

业务应用写入日志数据失败,mysql->日志tidb集群同步(1 OLAP汇总业务库也在日志tidb集群)也失败,不可用持续15分钟左右

疑问

1、tidb delete、drop、truncate是10分钟(我们用的默认)会自动进行空间回收,这10T表回收空间为何在24h后才进行?
2、为啥自动回收空间会对tikv进行大量写入?但没有读取量(热力图上看没有读取,但实际tikv机器是有最高250MB/s吞吐的)?
3、大空间表清除是不是不适合用truncate,有推荐方式吗?

cluster_display.txt (3.3 KB) edit_config_2021-09-10_14-32-30.log (1.2 KB) leader_reduce_tikv_09_08_22_25~42.txt.tar.gz (5.2 MB) pd_leader_09_08_22_25~42.rar (3.0 MB)

辛苦把不可用时间段前后 1 小时的 TiDB 、PD、 TiKV-detail 的监控导出。
https://docs.pingcap.com/zh/tidb/stable/exporting-grafana-snapshots#将-grafana-监控数据导出成快照

tidb_tikv_pd快照.rar (3.2 MB)
已重新上传
之前pd相关图表不全,已重新上传
tidb-log-PD_2021-09-13T02_40_56.344Z.rar (441.0 KB)

不可用期间tidb gc leader 日志
tidb_gc_leader_08_21_20_23_30.rar (78.9 KB)

tikv-detail 22-23:59 grafana监控图
tidb-log-TiKV-Details_2021-09-14T06_30_19.176Z.rar (2.2 MB)

  • 由于 cdc 这边 changfeed move 之后,gc 会保留 24 小时,所以这边是 24 之后才 gc 掉 truncate table 的数据。 然后由于删除的表太大了,在 delete range 删除了 大量 sst 之后, 导致 compaction 的数据太多了,导致触发了 rocksdb 的流控。
  • 建议在删除这么大的表的时候,可以把 soft-pending-compaction-bytes-limit 、hard-pending-compaction-bytes-limit 、 max-background-jobs 适当调高。