mydumper备份导致业务部分请求超时问题

环境 2.1版本集群 pd 3节点 tidb 3节点 tikv 5节点 所有机器都是千兆网卡,该集群只有一张innodb的大表(大概2T左右)

背景 单独部署一台tidb机器作为备份使用(这台机器是万兆网卡)

操作 在使用mydumper进行备份的时候会触发业务端的部分请求超时,备份过程中:(1)tikv的节点的网络开销能达到500Mb左右,io 达到60%这样,CPU没有负载。(2)pd监控也没有读写热点问题。所以想咨询一下这个现象背后可能的原因,以及这个备份操作能达到多少性能损耗。

备份命令 ./mydumper -u xxxx -p ‘xxx’ -h 127.0.0.1 -P 4000 -t 5 -F 256 --skip-tz-utc -o /work/back/4000

1 个赞

-t 参数要考虑CPU情况进行调整。-F 参数可以考虑调小。

考虑启用以下mydumper参数

–max_allowed_packet

服务器发送和接受的最大包长度。

–compress, -C

在客户端和服务器之间启用压缩传递所有信息

文档中描述,会lock table,这就会影响业务使用。不建议生产时备份,建议业务低峰期或者业务停止时进行备份。

需要的权限

  • SELECT
  • RELOAD
  • LOCK TABLES
  • REPLICATION CLIENT

另外注意文档中以下部分内容:
https://docs.pingcap.com/zh/tidb/v2.1/mydumper-overview#性能评估

mydumper备份原理如下
1、主线程 FLUSH TABLES WITH READ LOCK
2、Dump线程 START TRANSACTION WITH CONSISTENT SNAPSHOT;
3、LL Dump线程 LOCK TABLES non-InnoDB
4、主线程UNLOCK TABLES
5、LL Dump线程 dump non-InnoDB tables
6、LL DUmp线程 UNLOCK non-InnoDB
7、Dump线程 dump InnoDB tables

因为我们的业务就一个innodb表,所以备份期间需要获取的锁,应该很快就释放的,我们遇到的现象是备份过程中(每个tidb差不多都是1.5k QPS,总计就不到5kQPS),业务端持续有部分请求超时,并不是所有请求,所以我感觉跟锁关系不是很大,应该是还有其他原因。

PS:
(1)CPU都是40c,没有负载。
(2)因为我们需要使用Lightning 进行恢复,所以用了-F 256,这是官方建议。
(3)mydumper 应该没有 max_allowed_packet选项吧【mydumper 0.9.5 (0042e179b74fd9cd731be4550bee4c284c212be6), built against MySQL 5.7.24 这个版本没有找到max_allowed_packet选项】

别的原因估计就是资源消耗了,应该不是单机混合部署吧?(PS 为什么不考虑低峰期备份?)

性能评估

在 Dump 操作前需要进行性能评估。由于并发 Scan 操作对 TiDB、TiKV 集群都会产生一定压力,所以需要评估与测试 Dump 操作对数据库集群和业务的影响。

低峰期比较短,所以经常会因为没备份完导致影响正常业务请求

此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。