可以使用source导入，临时解决小表导入问题可以使用，如果长期有导入逻辑的话还是配置一个标准化的lightning脚本更好，标准化参数后，后续也只是执行sh

本身部署上，加上tiflash后，如果可以保证tidb资源使用没有瓶颈，可以不在意tidb-server变成3的情况继续使用2个 具体变化不太清楚因为啥，可能是觉得加一个tiflash，想要对应加一个tidb，将分析型查询进行隔离，专门使用一个tidb-server去支持

相同版本相同架构可以进行恢复，但是如果要恢复到已存在其他库的旧集群，需要使用–db指定库进行恢复，不可使用full

老师，请问这个报错为啥跟这个参数有关，是有什么不兼容SQL发送到tidb吗

携手奔赴下一个十年！ [image]

缩容之前，先尝试把tiflash副本全部归0看看

PD的low-space-ratio参数控制方法，就是按照tikv上报的capacity去做的调度

tikv有个参数： raftstore.capacity 允许的最大数据存储大小,默认使用当前磁盘容量

[7f0c773268db4697acf4dd5d63683b21] [429b98e110c4501a3f09b21af9031f9f]

可以看一下这个冲突数据检测机制： https://docs.pingcap.com/zh/tidb/stable/tidb-lightning-logical-import-mode-usage/#冲突数据检测

看一下 ./tidb-topology.yaml 文件全局参数那是配置了什么特殊的参数吗

https://docs.pingcap.com/zh/tidb/v6.5/alert-rules/#tidb_tikvclient_backoff_seconds_count 发生重试的次数，很卡有可能是重试次数多，具体还是需要看SQL慢在哪里。

去Dashboard的TOP SQL观察对应服务器对应组件的资源占用SQL是什么

不会，但是好像需要有

你挂一个在备份恢复试试，印象里tifalsh是需要挂载的，恢复时候要用到

tiflash上面挂在NFS了吗

做了内部限制，没有小于等于的，是在24h内

通过store输出信息确认IP地址，然后观察要恢复的tikv地址的leader_count和region_count是否有在上升，就可以判断了把。