集群节点的配置是不合理的， tiflash 做单独的部署吧

现在测试环境接入opencraw试试

先对操作系统做个基础检查

WM_GOODS_LOG 是以那个字段做的分区，是STORE_ID嘛

问题描述的具体点

就当个兴趣方向搞吧，提升自己的视野广度

后台操作 nohup br backup full --pd “…” --storage “…” > backup.log 2>&1 &

数据库是那个版本的

编辑成shell脚本在后台跑跑

阿里云 OSS 提供了 S3 兼容接口 ，因此 Dumpling 可以将 OSS 识别为 S3 存储进行读写。 实际上，Dumpling（以及 BR 和 TiDB Lightning）通过统一的存储接口设计，支持多种云存储服务，只要构造正确的 S3 兼容协议 URL 即可。

建议在社区多服务几年，然后重新考一份 ， 新年快乐。

Connection Count中的连接数浮动还是很大的，kill掉的是那类SQL ，是sleep吗

解决了没，看看相关的logfile是否定期清理

用tiup的 exec --command “sudo df -h” ，看看返回结果

NO_DECORRELATE() 提示优化器不要尝试解除指定查询块中对应子查询的关联。该 Hint 适用于包含关联列的 EXISTS、 IN、 ANY、 ALL、 SOME 和标量子查询，即关联子查询。

提前做好巡检和负载基线，遇到问题可以通过dashboard查查性能SQL， 严重的oom问题排查思路

集群的节点都是混部的，看着内存还算是比较正常

mark下

tikv_cdc_min_resolved_ts_no_change_for_1m 报警规则：changes(tikv_cdc_min_resolved_ts[1m]) < 1 and ON (instance) tikv_cdc_region_resolve_status{status="resolved"} > 0 and ON (instance) tikv_cdc_captured_region_total > 0 规则描述：TiKV CDC 模块最小的 resolved ts 1 分钟没推进。 处理方法：收集 TiKV 日志，定位原因。