BR备份报错:[pd] fetch pending tso requests error

pd这几个warning应该都是正常情况,看BR日志最后备份是成功了
和这个帖子情况很像,应该只是日志输出的问题。

1赞

这个报错好像并不能忽略,我们用这些备份的数据在全新的同版本TIDB集群中进行了BR全量恢复,最后出现以下错误:
BR日志文件:restore_full_20220317.tar.gz (11.5 MB)

后面这篇的日志描述的 SST 文件没下载完成?

备份的时候,是否按照官方文档上的要求配置了 NFS 给所有的 tikv?

TSO 请求错误是 PD这边的,但是不会导致无法下载SST的

上下游tidb的所有的tikv、tiflash、pd节点都有挂载这个nfs盘。
之前用v5.1.1版本的tidb时,br备份与恢复过程均没有出现错误,本周升级到v5.4.0后环境基本没有做改动,但是在用v5.4.0版本的br备份的时候就出现[pd] fetch pending tso requests error错误。

重新用 BR 跑一遍备份呢? 还是一样的问题么?

我们有备份任务每天都跑BR备份,我看今天的备份日志还是同样的问题,下图为今天BR备份的日志截图

PD 在 早上 7点20 - 7点 30 的监控信息有么?

环境的配置网络足够么?

tiup ctl pd看看pd member和health状态

这是24小时内的PD监控信息

tidb-app-PD_2022-03-18T03_18_49.727Z.zip (872.1 KB)

1、member信息:


2、health状态:


这个有点慢了…难怪报错的

那现在怎样才能解决这个问题啊?
我们BR备份时的–ratelimit参数设置的35,这个参数要调小吗?还是说要改其它设置?

–ratelimit 是限制tikv 速率的,对PD 没作用

  1. 在业务较少的时段,执行试试
  2. 追加硬件配置,满足性能要求

1.备份任务是在每天0:00开始的,8:00之前基本能结束,这已是业务量最小的时间段了。
2.应该不是性能问题,我看pd节点所在的3台服务器没有达到性能瓶颈,而且在v5.1.1版本没有这个问题啊,怎么升级了一个版本就出现性能问题了?
以下是3台pd节点服务器的监控信息:



可以参考这个来排查一下

话说能否检查一下硬盘的状态呢?看起来备份文件似乎已经因为未知原因损坏了,经验上这种状况大多发生于备份盘接近寿命上限的时候。(也可以将涉事 SST 下载下来使用 RocksDB 的 ldb 工具检查一下。)

BR工具已退回v5.1.1版本,备份过程未发现报错:


恢复过程也未发现错误日志,但是最后的这些error和fail信息不太清楚是什么情况。

["[pd] fetch pending tso requests error"] 报错是 TiDB 退出的时候有些日志打印的不太合理,可以认为对备份无影响,备份只要有 Summary Success 就是成功的。

增量恢复时出现报错 [“execute ddl query failed”] [query=] [db=db_ysb_order] [historySchemaVersion=34070] [error="[parser:1064]You have an error in your SQL syntax; check the manual that corresponds to your TiDB version for the right syntax to use run multiple statements internally is not supported"]

经排查上游存在空的 DDL query 导致,在这里跟进修复
https://github.com/pingcap/tidb/issues/33322

我这边也遇到了相同的问题,这个应该是BRv5.4.1的bug, 备份出来的.sst 文件大小为0. !!!

image

  1. 用上面备份的文件恢复会报错,和题主同学遇到的问题一样!
  2. 手动把上图中两个文件的文件名更换一下,就可以恢复成功

V5.4.0 BR备份提示相同报错:[pd] fetch pending tso requests error],但是在测试环境恢复成功。