br 工具完善

🪐 TiDB 技术问题
1

背景：自建 s3 备份失败，可否多打印一些信息让排查问题更有参考一些
数据库版本 v5.4.x ，br 版本 v5.4.x

希望改进：

  1. 上传失败会打印如下语句，应该是 s3 某些节点的负载高，所以可否打印一下是哪个文件上传失败了吗，目的是想输出个文件名，给下游的 s3 更多参考，谢谢

[2022/07/30 11:19:43.832 +08:00] [ERROR] [backup.go:40] [“failed to backup”] [error=“error happen in store 9349506 at xxxxx:20160: Io(Custom { kind: Other, error: “failed to put object rusoto error timeout after 15mins for upload part in s3 storage” }): [BR:KV:ErrKVStorage]tikv storage occur I/O error”]

  1. 可否吧timeout时长设置为参数可供调整
    failed to put object rusoto error timeout after 15mins for upload part in s3 storage

还有个问题：
如果发现了 s3 连接不上，br 的行为是 等待 还是 尝试继续重连？

2
  1. 这个日志可以加，但是会在 tikv 的节点上。
  2. timeout 这个参数目前是不能调整的，出现这个情况的原因是 s3 15min 没有完成 put/upload_part 请求。我们之前遇到的问题是不设置 timeout，但在 minio 上实际等待时间可能超过好几个小时，导致备份卡住。所以我们设置了 15min 的上限，及时返回错误，依靠外部 BR 的重试，绕过这个问题。
    遇到这个问题，BR 会有一定的重试机制，如果持续的失败，那么会导致最终的失败。

如果是存储负载问题，可以通过调低并发参数，比如 br concurrency 或者 tikv [backup] num-threads 来 workaround.

3

日常备份任务会有重试机制，这边的业务场景是，群集规模较大，备份需要30h，提这个参数的初衷是可以希望给底层s3更多的时间反应过来。

这个是 br 工具的 --ratelimit 这个参数吗？

4

集群太大后，遇到问题的概率就会升高，这需要 BR 对重试优化的更加健壮。

下面这些信息，是否方便提供

  • 目前集群容量多大？ 集群配置和拓扑怎么样
  • 备份成功时显示备份速度是多少？ （可以通过 backup 成功后的 log 的 summary 部分看到）
5

客户备份速度慢，有方法可以提速吗？

6

版本 v5.4.0
3pd 5tidb 9tikv ，集群 13T 左右
br 平均速度 284MB/s

我感觉根因是在备份 sst 或 checksum 的时，所有的tikv节点要和 s3 建立连接，如果网络不稳定或超超时，则会认定整个备份失败。

7

能想到就是备份的时间越长，遇到异常的概率就越大，此时异常处理就比较重要。

此外请问一下，你的集群也是部署在 aws 上的吗，是备份到集群同 region 的 s3 吗

8

集群部署在自建机房，S3 也是自建的

9

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