br备份cpu突增出现报警

🪐 TiDB 技术问题 备份&数据迁移
1

br备份在备份结束时，cpu总出现突增持续1分钟，
备份参数：
–ratelimit = 15
–CONCURRENCY=2
设置以及很小了，总会有一个节点出现cpu突增一下，是什么原因。

2
  1. 集群版本和 BR 版本是多少？
  2. 突增是增了多少？ 截图看下
  3. 固定某一个 TiKV 吗？ 机器配置是什么？
3

集群版本，4.0.10，采用tiup部署
br版本：v4.0.10
固定的一个tikv，配置，ssd，内存 251G

QQ%E5%9B%BE%E7%89%8720210420103351
QQ%E5%9B%BE%E7%89%87202104201033511166×613 66.6 KB

4
  1. 这里代表的是最高峰占用了 80% cpu 对吧。 其他线条也包含了，其他的 TiKV 吗？
  2. 能否麻烦查看下 grafana 监控里每个 store 的 region 和 leader 数量，多谢。
5

对，就备份的这个时间点，在备份结束的时候

6
  1. 麻烦反馈那个时间段的 grafana detail-tikv 监控。给一下，cpu高的时间点和对应的哪个 tikv store，多谢。
  2. BR 备份日志麻烦也反馈下，包含这个时间点前后即可。
8

具体要看哪项监控，我查下

9

QQ%E5%9B%BE%E7%89%8720210421142057

QQ%E5%9B%BE%E7%89%8720210421142219
QQ%E5%9B%BE%E7%89%8720210421142219898×677 132 KB
QQ%E5%9B%BE%E7%89%8720210421142305
QQ%E5%9B%BE%E7%89%8720210421142305906×345 26.1 KB

11

br备份日志：s_salekey_info_day]
[2021/04/21 02:35:32.343 +08:00] [INFO] [client.go:927] [“checksum success”] [database=cmc_ssbi_metadata] [table=report_gov_hall_movie_box_country_day]
[2021/04/21 02:35:32.344 +08:00] [INFO] [client.go:927] [“checksum success”] [database=cmc_ssbi_metadata] [table=dm_goods_items_info_day]
[2021/04/21 02:35:32.345 +08:00] [INFO] [client.go:927] [“checksum success”] [database=cmc_ssbi_metadata] [table=dm_goods_salekey_info]
[2021/04/21 02:35:32.346 +08:00] [INFO] [client.go:927] [“checksum success”] [database=cmc_ssbi_metadata] [table=dm_ticket_channel_online_day]
[2021/04/21 02:35:32.347 +08:00] [INFO] [client.go:927] [“checksum success”] [database=cmc_ssbi_metadata] [table=dm_goods_items_info]
[2021/04/21 02:35:32.348 +08:00] [INFO] [client.go:927] [“checksum success”] [database=cmc_ssbi_metadata] [table=report_gov_hall_movie_box_film_cinema]
[2021/04/21 02:35:32.446 +08:00] [INFO] [client.go:206] [“save backup meta”] [path=local:///data/backup/br/2021042101/fulldata_backup] [size=22943495]
[2021/04/21 02:35:32.538 +08:00] [INFO] [ddl.go:394] ["[ddl] DDL closed"] [ID=b7a3e790-582e-44ff-8eeb-40753fa42121] [“take time”=22.076663ms]
[2021/04/21 02:35:32.548 +08:00] [INFO] [ddl.go:303] ["[ddl] stop DDL"] [ID=b7a3e790-582e-44ff-8eeb-40753fa42121]
[2021/04/21 02:35:32.588 +08:00] [INFO] [domain.go:452] [“infoSyncerKeeper exited.”]
[2021/04/21 02:35:32.589 +08:00] [INFO] [domain.go:622] [“domain closed”] [“take time”=77.253461ms]
[2021/04/21 02:35:32.601 +08:00] [INFO] [collector.go:61] [“Full backup Success summary: total backup ranges: 3094, total success: 3094, total failed: 0, total take(Full backup time): 57m32.553383822s, total take(real time): 1h2m23.489751481s, total kv: 12415316882, total size(MB): 2203748.42, avg speed(MB/s): 638.30”] [“backup fast checksum”=9.328889455s] [“backup checksum”=4m38.122006653s] [“backup total regions”=33008] [BackupTS=424395404659916802] [Size=217734896919]

12

在备份快要结束的时候会在本地计算一下所有文件的 checksum；文件数量比较多的话这个可能会比较消耗资源，可以对一下日志里面 “fast checksum calculated” 的时间看看

14

我看了下，fast checksum calculated 时间基本和报警时间差不多，这种情况怎么优化，降低资源的消耗

15

tikv 节点cpu 高，可以考虑 --checksum-concurrency 降低并行度，默认是 4 ，调到 2 试试

16

–concurrency 参数和 --checksum-concurrency 不是一个是吧

17

–checksum-concurrency 这个参数在哪可以看到，文档中没有找到这个参数

18

目前是隐藏参数