类似情况内部有讨论过，初步结论，AI 总结： 将 TiKV 配置项backup.s3-multi-part-size 设置为 256MiB，避免通过 Multipart Upload API 上传备份文件，减少 CompleteMultipartUpload 的请求数量 ：BR 的修复已支持multi_part_size 可配置（解决原 5MB split size 生成过多请求的问题），并添加了备份 S3 存储的 metrics 以监控 QPS；长期计划将实现 流量控制器 ，自动控制请求不超过云厂商的带宽和 QPS 限制，替代手动调整参数 缓解方案 ：结合backup.enable-au…

还原是正常退出没问题么？ lightning 有 checksum 的。 或者说是不是因为大小写问题导致有数据重复导致的数据导入异常？

这个是新集群么？

低版本我记得有个 bug，绕过方法： 创建一个同名的任务，可以不同步任何东西 删除这个同名任务。 这样应该能清理。你试试。

报错上来看，看起来是 recover 的时候认为这个 pd 已经被初始化了。 我确认下，你这个 pd 是目录没有问题，只是多数派挂掉导致无法提供服务的情况么？

整个集群暂停操作做了么？ tiup cluster stop cluster-name

如果你已经确定这个 SQL 慢了，那你需要查看 SQL 执行计划是否正确。 https://docs.pingcap.com/zh/tidb/stable/explain-walkthrough/ 你得学会执行计划解读。 简单点方法，你可以将表结构和执行计划丢给 AI 先分析一波。

根据文件信息手动卸载吧。 当然你要是对 tiup 这个工具比较熟悉的话，可以根据 meta 信息来让 tiup 管理这个集群，然后用 tiup 来释放这个集群。 看下这个帖子：误删$home/.tiup文件夹，如何找回已部署的集群信息 - #3，来自 来了老弟

这里，看岔了。 storage 》em > clusters > em-test > meta.yaml

看起来这两个文件比较重要，看一下内容。 应该是 tiup 信息和集群拓扑信息。根据相关信息去卸载呢。

这个看起来是导出统计信息等操作：https://docs.pingcap.com/zh/tidb/stable/sql-plan-replayer/ 可能是之前执行过，然后没正常释放导致卡 gc 了吧。 看起来重启 tidb-server 后好了。

tidb server CPU 尽量单实例 40vc 以内，利用率比较高。cpu 使用率 80% 以上可以考虑扩容实例了 磁盘还好，注意配置日志和 tmp 目录，满了一般也不影响服务 内存不要 开 swap，oom 就优化 SQL 即可。

没试过 em 你看下 .em 的目录结果。 cd .em tree 结果发来看看

所以你其实是想删除 em 相关集群和 em 相关部署的东西？

我的意思是，你就当正常 tiup 使用有什么问题么？我理解你不就是想管理集群么？ tiup cluster list 这种直接敲什么结果呢。

看描述中控机有 .tiup 目录，你直接用 tiup 管理有报错么？ tiup cluster list 看看效果。

看标题，一边删、一般算。 如果你不是 select for update，我理解除非你删除自己有问题，不然不会死锁的。 不想幻读就用 RR 级别，但是读已提交更合理吧？

https://docs.pingcap.com/zh/tidb/stable/sql-statement-set-resource-group/ 有会话级别设置过么？可以按照这个文档看看登录这个账户后，绑定的资源组是哪个。