我觉得看图问题差不多定位到了，就是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文件没了，同样不能累加。

改了这个参数不会影响已经建立的连接。需要重建连接的。任务最好是重启一下。 连接数在dashboard上有面板，起码要看到这个连接数有波动，才是重建连接了。

1，ru是个很模糊/抽象的东西，只能凭感觉设置，如果设置了没限制住，再想办法调整。确实很反直觉，但是pingcap CTO推崇这个做法。在去年tidb走进b站——tidb上海站活动时，CTO也是这么说的。 2，50000还可以接受。90000的是真的需要优化一下sql了。 这个ru用的令牌桶算法。这是个经典的限流算法。所以整体超出ru上限的时候是按照限流来处理的。90000的sql你设置50000，那就是多执行1倍的时间，你设置10000，就是多执行9倍的时间。 3， 集群上所有数据库分配的总的RU，能超过集群预估的RU吗？ 可以，但不保证稳定。只在你明确知道这几个db的负载是错…

一般来说，只要Prometheus 不访问外网也不需要开身份验证的。 安全那边只有这一个方案嘛？防火墙的端口设置的严格一些不可以嘛？

最好是能提供一下执行计划

这是可以的。 不过缩容后，记得把副本设置回1，不然在那一台tiflash会有2个副本，占用2份存储。

可以自己对比一下么。发出来以后，后来的人都是看你写的报告。多带感。

你可以看一下这个回复。我看kafka的隐含的意思是，每个版本的kafka有个最小支持的api版本。只要高于这个最小支持版本都是可以用的。