pd这几个warning应该都是正常情况，看BR日志最后备份是成功了
和这个帖子情况很像，应该只是日志输出的问题。
BR备份报错：[pd] fetch pending tso requests error
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 跑一遍备份呢？ 还是一样的问题么？
PD 在 早上 7点20 - 7点 30 的监控信息有么？
环境的配置网络足够么？
tiup ctl pd看看pd member和health状态
那现在怎样才能解决这个问题啊？
我们BR备份时的–ratelimit参数设置的35，这个参数要调小吗？还是说要改其它设置？
–ratelimit 是限制tikv 速率的，对PD 没作用
- 在业务较少的时段，执行试试
- 追加硬件配置，满足性能要求
1.备份任务是在每天0:00开始的，8:00之前基本能结束，这已是业务量最小的时间段了。
2.应该不是性能问题，我看pd节点所在的3台服务器没有达到性能瓶颈，而且在v5.1.1版本没有这个问题啊，怎么升级了一个版本就出现性能问题了？
以下是3台pd节点服务器的监控信息：
可以参考这个来排查一下
话说能否检查一下硬盘的状态呢？看起来备份文件似乎已经因为未知原因损坏了，经验上这种状况大多发生于备份盘接近寿命上限的时候。（也可以将涉事 SST 下载下来使用 RocksDB 的 ldb 工具检查一下。）
["[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. !!!
- 用上面备份的文件恢复会报错，和题主同学遇到的问题一样！
- 手动把上图中两个文件的文件名更换一下，就可以恢复成功
V5.4.0 BR备份提示相同报错：[pd] fetch pending tso requests error]，但是在测试环境恢复成功。