【TiDB 使用环境】测试环境
【TiDB 版本】8.5.2
【部署方式】机器部署
【操作系统/CPU 架构/芯片详情】
【机器部署详情】CPU大小/内存大小/磁盘大小
【集群数据量】3
【集群节点数】3
【问题复现路径】做过哪些操作出现的问题
【遇到的问题：问题现象及影响】
使用BR进行恢复时，目的端TiDB中存在TiCDC的changefeed，为何changefeed停止后使用BR恢复仍提示需要remove changefeed，是有什么限制吗？
我看文档中只提到BR恢复时不能有TiCDC的数据同步，但changefeed是停止的状态是没有同步的。
1、BR 全量恢复的核心前置要求是：目标集群不能存在任何 TiCDC changefeed 任务，无论任务处于 running、stopped、warning 等任何状态，仅停止运行中的任务无法满足恢复条件。其底层逻辑在于：BR 是直接写入 TiKV SST 文件的物理恢复工具，会完全绕过 TiDB 事务层，导致 TiCDC 无法捕获这些数据变更。只要集群中残留任何 changefeed 任务（即使已停止），BR 就会判定存在数据一致性风险，直接拦截恢复操作，避免恢复后重启任务引发数据错乱。。
2、本质是不能存在 TiCDC changefeed 任务，而非不能有正在运行的同步。stopped 状态只是用户手动暂停了同步任务，任务的元数据仍完整保存在 PD 中，并未被删除：它会持续阻塞 GC 推进，且随时可以通过 resume 命令恢复同步。。
3、 仅执行 pause`命令将任务置为 stopped 状态，无法通过 BR 检查，必须用 remove彻底删除；同时，stopped 状态的任务会长期阻塞 GC，即使不做 BR 恢复，也建议及时清理无用任务，避免 TiKV 数据膨胀。。
肯定要remove重建的啊，数据库都还原了，原本记录的事务ID肯定不对了的
TiDB BR 恢复的校验逻辑不是仅判断 changefeed 运行状态，而是只要目标集群存在 TiCDC changefeed（无论 paused/stopped 状态），就会触发拦截
TiDB BR 恢复的限制不是 “不能同步”，而是 “不能有任何 TiCDC 任务元数据存在”。暂停没用，必须删除。
我感觉tso都不一致了吧
BR 在恢复前会查询 PD 中的所有 changefeed 记录，无论状态是正常运行还是停止 ，只要存在就会触发冲突检测
建议：
1、 恢复前停止所有业务写入
2、 完整备份当前 changefeed 配置，以便恢复后快速重建
3、恢复后验证数据一致性，再启动新的 changefeed
恢复完成后，重新创建 changefeed
不要直接 resume，必须删掉重建
指定正确的 start-ts（建议用恢复时间点）
TiDB 8.2+：BR 恢复 = 必须 remove 所有 changefeed（stopped 也不行）
pause 没用，必须 delete，恢复完再重建。
那是要在恢复之前就处理的吗
请问这个有官方文档说明吗？没找到这个
为了保证 BR 恢复操作的顺利进行和恢复后数据的一致性，必须删除 所有相关的 changefeed，
先删除有什么问题？还是顾虑？