问题描述的具体点

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

后台操作 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 日志，定位原因。

坚持出海，做大做强

当然是可以source ,也这么做了。 就是想验证import into from file 这个方法，文档中提到方式。在remove changefeed 后也没有import成功 ，ERROR 1292 (22007)

重新scale-out 了cdc ，list可以看到已有的changefeed的，是可以remove掉的。 [tidb@tidb01 ~]$ tiup cdc cli changefeed list --server=http://192.168.2.72:8300 Starting component cdc: /home/tidb/.tiup/components/cdc/v8.5.2/cdc cli changefeed list --server=http://192.168.2.72:8300 [ { "id": "pingcap-01", "namespac…

开发的SQL规范有时候很重要