确实是这个问题，调整检测端口之后，就没这个问题了，非常感谢
4 个月前
[image]
应该不是 tidb → tikv 的网络中断的问题，包括的两个IP指向都是tidb server节点，集群没有重启过，只从升完级，这个报错一直就有，感觉像bug
![[image]](https://asktug.com/uploads/default/original/4X/a/7/0/a70dedeac41d7fc1ed63e935218cbb416fd62515.png){kind=link}
4 个月前
![[image]](https://asktug.com/uploads/default/original/4X/f/2/f/f2f65f7208fa9a35e21939956f770c357e262cb2.png){kind=link}
这个版本号是执行tiup dm list查看到的
[image]
执行删除操作命名，dm-master输入如下的日志：就这一条
[2025/02/28 17:23:03.715 +08:00] [INFO] [server.go:2206] [payload="op:7 name:"tidb-xlg-mysql" "] [request=OperateTask]
4 个月前
嗯嗯，是这个原因导致的，设置max_execution_time这个比较小，导致超过个这个时间被中断了
9 个月前
场景描述：
物化视图可以说是目前某一类业务强需求，之前业务明确提过，当前的主要用在获量业务，涉及营销数据、各类游戏分析大盘等；
物化视图的基表5~10张左右，单个表的数据量大概在3000万左右，宽表，基表的数据有实时或定时的写入、更新和删除操作；针对当前TiDB不支持无法视图，业务采取其他的方案替代，按照目前的情况，延迟在10min以内应该是可以接收，具体可能还需要和业务确认
痛点描述：
您的系统是如何支持这些业务的，有遇到哪些痛点？
1、当前业务采用中间表的方式，预先将多表复杂查询的结果存储在中间表中，并且该表数据会更加业务时效性的要求，定时的进行更新；
2、子查询通过CTE表达…
10 个月前
最大4点收益：
1、高可用切换更加丝滑
2、减少很多对复杂AP类SQL语句的改写和优化
3、弹性扩缩容，业务几乎无感
4、数据迁移、流转、日常运维更加方便
1 年前
没有更多内容了