根据文件信息手动卸载吧。 当然你要是对 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/ 有会话级别设置过么？可以按照这个文档看看登录这个账户后，绑定的资源组是哪个。

是不是大小写问题，有试过全小写么

就是自己同步自己了。 cdc 不分别自己的 tidb-server 节点的。你相当于同步任务创建到了下游。。。

所以是自己同步自己？

ticdc 缩容前，有删除 changefeed 的么？ 你可以试试扩容一个 ticdc，然后查看是否有 changefeed 残留。如果有删除掉。 如果没有你创建一个同名的 changefeed 删除，再缩容掉 cdc 试试。

tiup 安装不会拒绝的吧？他只是 check 不过罢了。 docker compose 部署不推荐。别折腾了。

[img_v3_02t3_1725f8a8-b7ed-48fd-b60e-e700f58f9b6g] 数据量比较多。 tidb-server cpu 高其实也就是用了 4vc+。 是 gc 任务导致的。tidb-server gc owner 要算一些东西和扫 lock 的。预期性能损耗。 别不给资源跑后台啊。这么大数据量和集群。

update 最新： 这个是 TiCDC 新架构已知问题：TiDB Dashboard Compatibility · Issue #2128 · pingcap/ticdc，后续会修复，应该不影响使用