只能重新搭了，在这个集群再备份一份恢复到下游，然后备份的 committs 重新同步

其实只是不提供技术支持了，自己用用还是可以的，他这个主要是本来就不支持，与版本无关

br 是直接写sst 的，从原理上就不支持继续同步到下游 文档中有说明的 https://docs.pingcap.com/zh/tidb/stable/backup-and-restore-faq#为什么-br-恢复的数据无法同步到-ticdc--drainer-的上游集群

要配置 ignore-error = true ，否则开了 binlog 但是没地方写，会导致上游集群不可用。造成生产事故 看下官网配置：https://docs.pingcap.com/zh/tidb/stable/tidb-configuration-file#ignore-error

第一个sql 用 hint 能走到索引吗？

看图这个 tikv 节点已经是 “下线中” 了， 但是看监控 最近 10小时 region 的数量并没有发生变化。可以看看 operator 是否正常生成了。 参考下这个文档：https://docs.pingcap.com/zh/tidb/stable/pd-scheduling-best-practices#节点下线速度慢

有4个 tikv节点是新扩容进来的？ 那最开始集群中就是一个tikv节点吗？

可以看下这个： https://docs.pingcap.com/zh/tidb/stable/dm-handle-performance-issues#读取-binlog-数据

tidb_stderr.log 都是关于 expensivequery 的， 可以看下ls -ltr 看下这个文件的最后输出时间和 tidb-server 重启的时间是否能对得上，如果能对上可能还是慢查询导致的。 另外这个版本很老了，一些日志不一定打印的很全，推荐尽快升级到v6.5 以上的版本吧，内存限制优化了很多。

tidb 日志中搜下 “Welcome ” 然后往上看下 tidb节点重启前最后几条日志是什么

没太看懂你的描述，几副本是整个集群的配置， 你说的 4个 tikv 节点3副本， 1个tikv 节点1副本是怎么配置的？

tidb 日志中搜下 expensive 看看没执行成功的sql占用了多少内存

tidb 日志中搜下 expensive 看看没执行成功的sql占用了多少内存

default_collation_for_utf8mb4 可以改这个参数试一下

可以收个 profile 发出来看下 收集方式如下： 开启heap收集，执行命令后等待2分钟 curl http://:<status_port>/debug/pprof/heap_activate?interval=60 查看收集结果 curl http://:<status_port>/debug/pprof/heap_list 将第二步中收集结果拷贝出来 关闭heap收集 curl http://:<status_port>/debug/pprof/heap_deactivate jeprof --svg <prof.heap> > out.svg

看下 grafana 监控 tidb -server 中的panel，可以截图发出来看下

可以把 grafana 监控利的 resource control 监控发出来看下

理论上 tidb_analyze_version =2 修改的统计信息更准，算是一个优化点， 注意修改完成后，要重新收集统计信息才能生效

可以看下这里 ：https://github.com/pingcap/tidb/blob/master/docs/tidb_http_api.md