TiProxy 和 TiCDC 支持的新特性 Debezium

统计信息没有过期是什么问题呢 ？ SQL发出来看看呢。

还有一个路径也可以，就是查看 performance-overview 这个面板的这个会显示Active connections [image] [image]

最直接的就是在 prometheus 中查询 tidb_server_tokens 这个表达式，只有这个表达式才代表了并发连接。 tidb_server_tokens The number of concurrent executing session TYPE tidb_server_tokens gauge tidb_server_tokens 0

这个日志出现没关系，后面显示为 dump data successfully, dumpling will exit now。这个地方是 [info]

用/*+inl_join(tt1) */ 试一下。

最最上乘的办法就是通过统计信息来解决，但是这也是最难的。 统计信息解决不了的，才分两种情况。如果是出故障的就去绑定，没有出故障的就应用自己去解决。

其实存多了不能看，还不如不存多。只存主要的。 https://github.com/pingcap/tidb-dashboard/issues/1386 [image]

这个东西不建议改，改大了会有风险。理由是，sql语句存的过多，有时候你去查，要decode 这个plan，有可能会导致数据库OOM。这个有对应的issue。就设置3000就行了，多余的本身就是不怎么活跃的，要不要无所谓。

你可以研究一下这个工具 PCC pingcap A tool used to capture plan changes among different versions of TiDB [image]

我希望是能出现一个整合和总结的，比如你发一个问题，他先回复你如何解决，然后下面列出引用出处（比如论坛中的经验）。

看下 grafana 监控吧。像是压力太大了导致的，把 topsql 分析分析。

这个报错遇到过，一般是应用程序和数据库之间中断了。

你的 tidb_analyze_version 设置的多少？ 这个报错很明显了。only support analyze version 1 currently

内存使用太快了，还来不及dump就OOM了。所以建议开 topsql 功能呀，那个是端到端的技术。

那就是太快了，都来不及记录就down了，你这 6.1 可以把topsql打开，这样down了，topsql还是有记录的。

这样我们就可以只专注于核心的表进行备份。

对于这个问题我有一个新的想法，就是 逻辑备份+ ticdc to cos。 我们首先基于时间点进行逻辑备份，然后在做 ticdc to cos 的增量。不过得对这个文件自己解析来做数据的增删改。 [image]

感觉网络上有一些问题。可以看下 blackbox 的监控，主要是 tidb->pd ,pd → tidb 的链路看看