已知问题，升级版本可以修复 sync load cannot stop to retry when to load empty stats · Issue #52657 · pingcap/tidb (github.com)

已知问题了，升级版本可以修复。 sync load cannot stop to retry when to load empty stats · Issue #52657 · pingcap/tidb (github.com)

和tiup管理tidb集群一样的 tiup dm stop cluster-name -N IP:port https://docs.pingcap.com/zh/tidb/stable/tiup-component-dm

https://docs.pingcap.com/zh/tidb/stable/dm-error-handling#原因 你看下官方文档给的解决方案 [image]

INFORMATION_SCHEMA.TABLES 里可以查到tableid

tidb没有传统意义上的表空间概念。TiDB的数据以Region为单位分布在多个节点上，自动处理分片和负载均衡。 插件是什么？

我所有kv节点安装配置都是一样的，只有操作系统版本有差别。 [image]

我这有套集群kv节点混了centos7和rocky9部署的，rocky系统使用的内存比centos7高百分之20。

你这个olap场景非常建议上一个tiflash，查询速度会起飞。

第一次见tidb节点比kv节点还多的，我猜资源都被慢sql占用了，优先优化慢sql吧。

deepseek给的答案也是通过网络检索后归纳总结的，只具备一点点参考性。 [image]

这个update可以执行成功，但是实际无效。

new_collations_enabled_on_first_bootstrap这个参数是在集群第一次初始化的时候设置的，老版本默认是false，就是默认大小写敏感不支持修改表的collation 排序 新版本new_collations_enabled_on_first_bootstrap是默认true，老集群只能单独对表设置排序规则。 我之前遇到过类似问题

好东西，坐等体验。

各种故障排查合集

mpp得列存，tikv的低层数据架构没法支持，你可以用tiflash支持mpp的。

tidb非常稳，没出过故障

常用的就tiup、dumpling、br、cdc、binlog、tifash，基本够用了。

你让客户去咨询下运营商稳定的专线要多少钱，可能他就放弃了这种异地容灾的想法了。