connect id 看看能不能找到对应时间前后的。

不可能吧，除非你是一个事务里面的 sql，慢日志只记录 commit 和上一个 sql。 不然应该不会找不到的。

这个 sql ，慢日志内容发下，里面应该有 cost time 的分布。

expensive 记录有两种，一个是 scan key 比较多的。一个是执行时间超过 60s 的。 你们集群是不是 scheme 比较多？导致 use database 的时候加载的慢。 你登录数据库 mysql -A . -A 可以跳过一些加载看看快不快。

redo 盘的问题，换了就好了。

你要不要试试升级到 7.5.6: 2025-03-14 试试能不能解决

你 bind 长啥样？ 给个最新复现方法吧。

总结： 目前怀疑是 NAS 硬盘速度慢导致删除 redo log 很慢 由于删除 redo log 是在 owner 的 Tick() 里前台执行的，这一步慢就会直接卡住 Tick() Grafana 的 Ownership history 是统计 owner 的 Tick() 是否有按时执行，所以 Tick() 卡住就会显示为 ownership = 0，虽然选举意义上的 owner 实际上没有变化 相关日志： Jul 22, 2025 @ 17:05:26.437 ["handle admin job"] [changefeed=lego-level-tianji-bk] Jul …

下游写的 kafka 么？ [image] https://docs.pingcap.com/zh/tidb/stable/release-7.1.6/ [image] 你不行试试升级一个小版本看看。

[image] 看你之前卡，应该是刷 redo log 超过 31m 了，感觉你刷 redo 的目标盘很烂。如果没有好的硬件不行 redo 就别开了。 后面看日志有 [2025/07/21 20:12:52.314 +08:00] [INFO] [helper.go:83] [“got signal, prepare to shutdown”] [signal=terminated] 看起来是主动关掉的 cdc 节点，当时应该有 owner 的，看是 222 这个节点 cdc 就是，应该是关闭之后 owner 没选出来？ 你要不现在试试删 changefeed 吧。

那是的，那你吧 changefeed 删了再试试。

还有，你存 redo log 的盘是什么盘？ssd 么。

有 owner 了我理解你就能创建任务了。

这个可以关，tidb ticdc 的同步 redo 是做灾难一致性恢复用的。不开这个问题也不大。 https://docs.pingcap.com/zh/tidb/stable/ticdc-overview/#最佳实践

开了 redo log ？试试关闭看看有没有效果。 看这个日志的意思是刷日志 block 了。

包涵的，1 是超过 60s 二是超过一定扫描量就会记录 expensive sql

比如对应符合条件的数据是不是很多，有没有大字段。

expensive sql 是 60s 抓一次，并不是实时的。而且 sql 统计内存和系统分配内存也不是完全能对上，低于实际值也正常。 你可以先判断下这个 update 的内存消耗正常么。

cop 应该有数据扫的操作 你是 tidb-server 节点内存突增还是 tikv 的高。 如果是 tidb-server 节点内存突增，看下这个节点慢日志有没有内存用的多的 sql 看下增加前后 tidb.log expensive 关键字的日志，里面有记录耗资源高的 sql