资源管控确实偏向tikv多一些。 [1744975125221] 不过，这里distsql就是去tikv上取的数据。你控制tikv的读取速度，有希望间接控制。算是个不是办法的办法。 另外就是慢查询里面找不到可疑的analyze？ 如果还是慢查询里面没有，也可以尝试等内存飙高的时候去topsql界面看看。 https://docs.pingcap.com/zh/tidb/stable/top-sql/#tidb-dashboard-top-sql-页面

这个问题在7.x版本以下确实有一些反馈，在8.5这个版本上不太应该有这个问题。 我有点怀疑是不是有些连接，在seesion级改过这个变量。 不过8.5版本也有一些方法对付这个问题。 首先是假如是个analyze的话，这个analyze应该是会进慢查询的。不太可能什么都找不到。 然后就是8.5的资源管控是可以控制后台任务的资源占用的。可以考虑给这些后台任务加个资源组。这样运行的时间无非是长一些，不至于影响整体的系统稳定性。 https://docs.pingcap.com/zh/tidb/stable/tidb-resource-control-background-tasks/#使用…

这个帖子，我看了下，感觉结论是靠谱的。 [image] 这个错误，要么是证书有问题，要么就是tls一些低版本协议，在高版本的dumpling下不支持了。 除了这2个方向，我想不出有其他可能性，会导致握手直接失败。 所以应该考虑安装一个低版本dumpling，设置好证书再试试。 tiup install dumpling:v5.1.0 类似上面这样，安装一个5.1.0版本的dumpling试试看。

https://docs.pingcap.com/zh/tidb/stable/dumpling-overview/#dumpling-主要选项表 –ca 用于 TLS 连接的 certificate authority 文件的地址 –cert 用于 TLS 连接的 client certificate 文件的地址 –key 用于 TLS 连接的 client private key 文件的地址 你得把ssl的证书带上

每个节点的负载不一样吧。 看看topsql界面，负载差异是不是很大。 https://docs.pingcap.com/zh/tidb/stable/top-sql/#tidb-dashboard-top-sql-页面

这个方案怎么说都是可行的，你本身就是ticdc+kafka的模式。就算ticdc上过滤不了，你的kafka上肯定还有个应用往下游写的，在这里过滤也可以做到。 所以方案我觉得怎么样都能做的，是可行的。 不过我觉得你的处理方法太绕了。我还是信奉“如无必要，勿增实体”。现在的问题是运维操作删除数据有可能误删除。应该想办法在源头解决问题，而不是发生了这个问题再去拦截。 如果能做到运维操作删除前先备份，保证删除可回退，就算这些操作被复制到下游也是能挽回的就好了。 放任源头不管，会增加很多解决问题的复杂度。最后很容易引入更大的麻烦。

你看看这个内存飙高的机器是不是ddl owner https://docs.pingcap.com/zh/tidb/stable/sql-statement-admin-show-ddl/#admin-show-ddl 我看这个profilling像是ddl onwer在做auto analyze，然后analyze的表里面有个json字段。导致的内存飙高。

我觉得看图问题差不多定位到了，就是apply wait duration有问题。 100ms的时候就有问题。因为其他延迟都很低，100ms已经是3-4倍的慢了。 现在往下查，要查一下网络是不是有问题，ping值是否正常，流量是否有打满的可能，tcp retrans是否正常。 如果网络没问题。grpc的线程是否需要调整一下 https://docs.pingcap.com/zh/tidb/stable/three-nodes-hybrid-deployment/#servergrpc-concurrency 查查tikv grpc相关的指标延迟高不高。

ping没法证明这个端口是开的。还是不建议猜，最好能坐实这个端口是否能访问。

一般重启一下应该是能解决的。 报错说找不到开启元数据锁的这个全局变量。这个变量确实是比6.1版本要高的时候才会有的。 起码你报错的这个节点，应该是升级成功的。不然不会去找这个变量。 https://docs.pingcap.com/zh/tidb/stable/metadata-lock/#使用元数据锁 在 v6.5.0 及之后的版本中，TiDB 默认开启元数据锁特性。当集群从 v6.5.0 之前的版本升级到 v6.5.0 及之后的版本时，TiDB 会自动开启元数据锁功能。如果需要关闭元数据锁，你可以将系统变量 tidb_enable_metadata_lock 设置为 OFF 。 …

已经EOL的版本你研究这个没太大意思了啊。 你就算定位到铁证如山，它是个5.2版本的bug，问题是没人来修了啊。

apply_batch_wait是明显的高于其他一切。 apply里面total只有1.91ms。但是apply_batch_wait就占了386.4ms。 问题看上去就在apply这个环节里面。把相关监控都翻出来研究一下吧。

192.168.0.11 192.168.0.14 这2个机器的2380都连不上，telnet试一下能访问到嘛？

根算子是hashagg，说明这个sql是个典型的聚合计算，这种sql要想快，必须上列存，也就是tiflash节点。 5.2.1这个版本太老了。在行存也就是tikv这个架构上做，扫描的数据量是怎么样都很难减小的。5.2版本也已经结束支持了，EOL了。 https://cn.pingcap.com/tidb-release-support-policy 还是安排升级，尝试使用tiflash才是tidb体系下，最好的解决方案。

https://docs.pingcap.com/zh/tidb/stable/task-configuration-file-full/ 你肯定是自己改了task里面的默认配置。 dm只在dump阶段有可能需要用到FLUSH TABLES WITH READ LOCK， mydumpers: # dump 处理单元的运行配置参数 global: # 配置名称 threads: 4 # dump 处理单元从上游数据库实例导出数据和 c…

不太熟悉k8s，不过看上去问题在于 ti-q7mro677hz15i9ufsdul-pd-2.ti-q7mro677hz15i9ufsdul-pd-peer.ti-q7mro677hz15i9ufsdul.svc 这个地址完全访问不了。网络层面就不行。

应该是可以的。 带–remove-meta的话，是彻底重建task。将会走完完整的dump ，load，sync阶段。 不带的话，就是从sync阶段上次记录的binlog位置开始task。

你的dm集群的版本低了，6.1.7 你的dmctl这个工具的版本比这个dm集群的版本高。 所有一些api可能找不到了。

dump阶段是要记录binlog点位的，然后开始全量导出应表的数据的。 每次重开dump阶段binlog点位记录的都不一样，就没法累加。 上次dump的数据多少是缺一点的，没法信任了不是么。 到sync阶段就好了。但是如果sync阶段上游对应的binlog文件没了，同样不能累加。