确实 oracle duplicate 跑完之后，开启备库实时应用确实方便

你就按照lightning 这种样式配置的试试

你说的应该是这个： [image] lightning 配置修改： https://docs.pingcap.com/zh/tidb/stable/release-8.1.0#配置文件参数 [image]

PITR 不推进可以先按照这些 issue 排查下，有没有对应的 info 输出： https://github.com/tikv/tikv/issues/16554 https://github.com/pingcap/tidb/issues/53047 https://github.com/tikv/tikv/issues/17249

可以先按猫哥说的定位下问题： 之前碰到过一个类似的连接泄露的问题： 使用 auto_id_cache 的表特别多的时候，或者是 infoschema reload 过程，或者是有大量 DDL 的时候会发生这个连接泄露；

第一张图的话： 你看下对应指标在 grafana 显示正常吗，如果也不正常可能是普米的问题亦或是对应 node-exporter 有些问题；如果正常，那可能就是 dashboard 的显示问题了 第二张图： 从这个cpu使用率和内存使用率陡然间下降，大概率是 OOM 了，可以尝试查下 tidb.log 和 message。然后按照 OOM 的排查方式去看看。

之前有碰到有个tikvnode 本地可用空间不足 10%，且开启 fast_ddl 的情况下，加索引报错这个的

从你这个监控也只能从 backup 方面看看有没有什么异常了

感觉 tidb 侧多多少少有点问题，这个sql 的话并发度很大在执行吗？对应表中是不是有很多大的 varchar 了？

这个 issue，https://github.com/pingcap/tidb/issues/52826，，可以看下 sql statement 中有没有时常执行这个 sql，如果没有的话，就应该不是这个问题 [image]

可以看下 topsql 和 internal sql，这个版本好像有个 internal sql 导致内存使用率高的 bug

通过你的监控看不出啥问题，就是第二张图，部分 tikv 透明大页没有关闭，和部分 warning 报错 block-cache 使用的超过了默认值，不过也问题不大。

log backup 日志提供下看看嘞

手动调整–checksum-concurrency， 默认值是 4，可以调为 1，对集群中表/分区表多，索引多的这种环境有很大改善。

我理解你执行 sql并发高或者说 sql 本身内存使用率高导致 tiflash oom 是正常的啊。你需要解决多并发的什么问题了

这个无所谓的吧，tidb会自行backoff的

业务低峰期操作

是的 有实操

多 KV 节点就是符合预期的