BR备份报错rpc error: code = Canceled

另外,22:50 左右是有业务跑批吗?看起来在这个时间点,服务器的 load 以及 iops write,read latency 指标都有变化:


并且,这个时间点和 PD log 第一次出现 apply request took too long 的时间有吻合:

[2021/04/05 22:50:06.733 +08:00] [Warn] [util.go:144] ["apply request took too long"] [took=255.488221ms] [expected-duration=100ms] [prefix="read-only range "] [request="key:\"/pd/6846941113233660477/gc/safe_point/service\" range_end:\"/pd/6846941113233660477/gc/safe_point/servicf\" "] [response="range_response_count:1 size:148"] []
[2021/04/05 22:50:17.607 +08:00] [Warn] [util.go:144] ["apply request took too long"] [took=248.037498ms] [expected-duration=100ms] [prefix="read-only range "] [request="key:\"/tidb/server/minstartts\" range_end:\"/tidb/server/minstarttt\" "] [response="range_response_count:1 size:117"] []
[2021/04/05 22:50:38.952 +08:00] [Warn] [util.go:144] ["apply request took too long"] [took=197.537683ms] [expected-duration=100ms] [prefix="read-only range "] [request="key:\"/tidb/ddl/all_schema_versions\" range_end:\"/tidb/ddl/all_schema_versiont\" "] [response="range_response_count:2 size:210"] []

test-cluster-Disk-Performance_2021-04-07T07_29_18.127Z.json (82.5 KB) TIDB版本是v4.0.0

请参考上面 Disk-Performance → Disk Latency → Write Latency 截图的方式显示下磁盘的写延时
当前的监控信息没有显示写延时,仅显示了读延时:

这两块的信息也请提供下 ~

22点44左右做完的日结,是不是备份会受到大事务的作业影响?

1 个赞

因为当前的环境 PD,TiKV,TiDB 部署在同一台服务器上,牺牲了高可用和分布式的特性。除此之外,PD,TiKV 共用了一个数据目录 ~

如果是在 22:44 左右开始业务跑批,从 Node-Exporter 监控可见,服务器的 Load ,以及磁盘的 Read 和 Write Latency 都升高了。不排除跑批和 BR 备份任务相互影响的可能性,从 PD 的监控也可以得到一定的印证,如下:

故,怀疑因为 TiKV 和 PD 共用数据盘,可能是跑批任务影响了 PD 处理消息的速度,最后影响了 BR 备份。建议错峰进行 BR 备份,再观察下备份的情况 ~

收到,我马上调整一下

调整后,请将 BR 备份的结果同步下哈 ~

另外,想了解下,这个是生产环境吗?如果是生产环境,下面的信息需要关注下。其次,我们单节点跑 TiDB 集群是基于什么因素考虑呢?

1、单节点是生产环境,客户预算有限
2、软件开发后数据库做为根基,肯定是不能变了,为了降低运维成本
3、昨天备份成功了,第一次备份成功也是备份时间和日结错开了
非常感谢!结案

了解了谢谢,:handshake::handshake::handshake:

单节点架构没有高可用性,可以关注下灾难恢复工具,如 pd-recover