https://docs.pingcap.com/zh/tidb/stable/tidb-configuration-file#logfile 试试 max day

你这个不算长，sql 语句本身长，比如你 in 很多，sql 文本长度达到 MB 级别。

这个参数我查了下 ，应该就是保留多版本配置。按照说明看起来就算是正常删除，其实物理上也没有删除的。 看起来需要一些特殊参数指定删除。我理解 br truncate 不兼容这个也正常。 不过看描述参数关闭了 br truncate 也还是会保留一个空目录？

这个配置是什么意思？ 看起来是多版本存储？删除不是删除 而是打一个 delete 标签吧。

你提供下复现操作，我改成产品需求让人看看。

常见原因一般是 sql 过长或者 tidb-server 的 cpu 使用率很高。 如果不是 1 ，可能和 go gc 有关系，可能当时内存在回收 或者可以试试 tidb-server 绑核，配置下 numa_node，服务器上装 numactl。https://docs.pingcap.com/zh/tidb/stable/hybrid-deployment-topology

意思是文件删除了，但是目录还在的意思么？

不存数据，只参与投票那种？还没有这个功能。。。

pitr 重启下试试，感觉夯住了。 版本推荐升级到 7.5.5 我看还是修复了几个 br 相关问题的，但是不确定有没有覆盖你这个情况。

另外开个贴吧。你这是 tiflash 同步数据失败了？写一写操作背景。这个单的楼太高了。

tiflash 不要单机多实例部署。

怎么解决的？

可以这么用的，pitr 可以单独就刷增量部分。 比如主从 tidb 到 tidb 同步，延迟过高，用 pitr 备份的增量日志来刷数据。

https://docs.pingcap.com/zh/tidb/stable/backup-and-restore-use-cases 用这个案例测试，指定全量备份路径、增量备份路径、恢复到的目标时间。

增量恢复报错是啥呀。为啥判断没有恢复。。

br 的增量会自己卡 gc。 恢复的时候读取的是你备份 s3，不影响上游写。你要是发现 s3 或者本地盘性能跟不上，优先恢复，暂停应该也行的。

增量恢复不成功报错是什么，而且官网案例并没有用 start-ts ，你这里的命令是哪里来的呢？https://docs.pingcap.com/zh/tidb/stable/backup-and-restore-use-cases

那就是还原完成了。