集群A完备数据正常恢复，PITR的Restore Meta Files阶段100%完成，但Restore KV Files时进度一直为0.00%，如下图：
集群A除了用br跑备份恢复，也没有其它特殊操作，然后看到“PITR 仅支持恢复到全新的空集群”
因为我每次恢复完备数据之前，都会drop掉除系统库外的其它数据库（即：只保留INFORMATION_SCHEMA、METRICS_SCHEMA、PERFORMANCE_SCHEMA、mysql这四个库），于是怀疑是因为之前用br跑了备份恢复，导致A不是“全新的空集群”了。所以我新建了集群B，用同样的数据往集群B做恢复，结果目前跑了几次，都能成功恢复，如下图：
目前有两个疑问：
1.集群A在Restore KV Files阶段进度一直为0.00%，可能是什么原因造成的？
2.既然“PITR 仅支持恢复到全新的空集群”，为什么集群B可以多次完成PITR恢复？
一般只保留系统database是可以恢复成功的，这个卡住的看看br log在打印什么呢？
“Restore KV Files时进度一直为0.00%” 持续多久？ 是你手动退出还是自动退出的？ 日志最后一行有没有什么信息
目前看来如果不手动退出可能会一直持续下去，上边日志是我刚跑的恢复任务，可以挂在那试试会不会自动退出。昨天那个手动退出（控制台ctrl+c）后有一行错误日志，如下：
BR 卡住的时候可以通过如下步骤启动 pprof 并且抓到 goroutine dump，如果可以上传的话对诊断会很有帮助：
SIGUSR1: pkill -USR1 br 或者 kill -USR1 $(pgrep br)$pprof_port。curl http://localhost:$pprof_port/debug/pprof/goroutine?debug=2 > goroutine_dump.txt 获得 goroutine dump。目前来看取消时候的堆栈是准备 split 的时候在 scan region（这是 restore file 的前一步），但是似乎也看不出来啥。
看下是否有用呢
goroutine_dump.txt (163.0 KB)
前面日志看不到了，BR 的版本是多少呢？
需要重新启动个任务再获取goroutine dump吗？
集群 A 的数据是都清空了对吗？可以使用 pd-ctl 看看它当前的 region 吗？（pd-ctl region，这个命令可能会返回一个很大的 JSON，推荐运行的时候重定向一下）
看起来像是在 split 扫描 region 的过程中，没能正确处理最后一个 region（即，endkey = “”）的 region 导致的 bug。而扫描到最后一个 region 的原因，可能是没有恢复到全新集群，因此 DDL 相关的处理出现了问题，导致数据表没有建出来，因此没有触发表边界的 split。
另外，现在应该已经不推荐单独使用 restore point 了，可能的话还请周期性做 full backup，并且在恢复的时候指定 --full-backup-storage 来与 full backup 一起恢复。
以及前面的日志似乎丢了，方便再上传一下吗？
是清空了，但是restore point之前都有restore full的，只是restore full和restore point分两步执行的，图中都有记录的。
br.log.2025-06-05T15.06.29+0800 (74.1 KB)
br.log.2025-06-06T09.56.41+0800 (247.2 KB)
goroutine_dump.txt (163.0 KB)
br.log.2025-06-05T15.06.29 (74.1 KB)
br.log.2025-06-06T09.56.41 (247.2 KB)
奇怪，我本地去掉+0800，上传后又自动加上了。
这是执行pd-ctl region返回的JSON：
region.txt (57.0 KB)
应该没啥影响，这应该是 br 的 bug。只不过正常恢复到全新集群的情况下很难触发。
drop掉除系统库外的其它数据库 == 清空数据 == 全新集群，可以这样理解么？还是说前两者是同一个概念，全新集群仅仅是指通过tiup deploy，且没有任何数据变动得集群。
