你上面查的是 tikv 的日志，扩容期间有这个日志是正常的，不算报错，你可以看下 cdc 的日志里有没有什么有用的信息

cdc 的报错是啥？ 你提供的信息里看起来 cdc 的状态是正常的 [image]

目前从产品层面没有硬性限制， 但是如果备份正在恢复的表，可能会导致该备份集不可用，如果使用这个备份集再进行恢复的话，查询时可能会有 Default Not Found 一类的异常。 目前内部已反馈文档优化，后续会改为：“不建议备份正在恢复的表，可能会导致备份集不可用”

可能是mdl 锁卡住了， select * from mysql.tidb_mdl_view 看下

是从什么版本升级上来的？

在 ~/.tiup/storage/cluster/clusters/<cluster_name>/ssh 目录下有一个 id_rsa ,你用 ssh -i 的方式用这个密钥试试看能不能ssh 到对应的要扩容的节点上

https://docs.pingcap.com/zh/tidb/stable/grafana-pd-dashboard#pd-重要监控指标详解 可以看下这个

那要看你要看什么信息了，我建议你先研究下pd的监控 大部分 region的调度情况都在监控能看出来，除非你要精确到具体某一个region 或者精确到秒级别 否则看监控就行了

tikv 和 pd 的日志会记录，但是这个日志量很大，不确定你能否筛选出你想要的信息

那上游存在的是聚簇的还是非聚簇的呢？如果只是下游 肯定有一张表是多余的，看看能不能把多余的表删掉

那你的上游是什么样的？ 同名的表也有两张吗？

你还用clicloud用户扩容，对应的权限有关的报错是什么呢？ 按照报错把权限赋好也不行吗？

你这用户有点乱啊， 一会 root ，一会 hcicloud ，还有 tidb 用户。。

预期情况就是用部署 tiup 的用户去操作 tiup ，如果权限不足就先解决权限的问题呢？

前面是如何确认 oom 是和 analyze 相关的？ 可以搜下 tidb-server oom 前的日志 ”expensive“ 是否有大sql analyze version 倒是有个 oom 的bug ，但是v5.4.3 已经修复了 https://github.com/pingcap/tidb/pull/28729

我看你描述写的 部署tiup 的 用户是 hcicloud ， 为啥下面都是在用root 用户操作 su 到 hcicloud 这个用户，然后不指定 --user 有试过吗？

可以创建 tidb-deploy 指的是 tiup 已经自动创建出来了吗？ 还是你手动创建的？

other 包含 tikv 中其他的读流量，就是这个面板中没显示的流量，不太好判断具体是什么 这个面板中 ForegroundWrite 是用户写入，read 是用户读取，level_zero_compaction 是 rocksdb l0 compaction 流量，LoadBalance 是 region 调度导致的流量，flush 是 rocksdb flush memtable 的流量。 可以通过 grpc 或者 coprocessor 面板看下other io 高的集群 有没有其他的流量比较高

看下 grafana TIDB 监控页面 pd client 的相关监控 ，get tso 是不是延迟很高