batch效率挺高的，默认是单线程执行的不会对集群负载造成大的压力，删除的时候磁盘读写肯定会上涨、

你的binlog日志是不是这样500M一个归档了？自己写个脚本打包备份下就行了。 find ./ -type f -size +510M | grep -v “.zip”|xargs zip $date1 | xargs rm -rf [image]

此话题已在最后回复的 7 天后被自动关闭。不再允许新回复。

【你的业务中混合使用了哪些数据库？它们各自承担什么角色？】 mysql redis es clickhouse tdengine hbase，各有各的用处，啥场景是合适什么就用什么，比如es适合全文检索。 【跨库场景下，哪个问题最让你头疼？】 etl 同步数据到hadoop或者时序数据库tdengine

类似的问题看下。他那个排查下来是dumpling备份msyql5.7兼容性有问题。

可以使用binlog skip -h跳过操作 具体你看下文档https://docs.pingcap.com/zh/tidb/stable/handle-failed-ddl-statements/

看了7天监控，所有指标每天都在上涨 [image]

没有部署k8s的数据库系统，以后也不会用。 1、数据库性能要求较高，k8s的数据库集群会多一层网络开销，响应性能会损失能大 2、k8s系统需要一个成熟的运维团队维护，复杂度高，排查问题繁琐，不然出问题根本解决不了，数据库出问题不是等着领大礼包么。

ng-mintitoring采集数据存储在tsdb中，tsdb中数据量非常大， 修改/data/tidb/tidb-deploy/prometheus-9090/conf/ngmonitoring.toml增加retention-period = “15d” 没有生效 删除tsdb目录后，重启了下ng-monitoring-server ，空间释放，内存就降下来了。

tikv的cpu高，大部分原因是慢sql造成的，dashboard中看下topsql 情况，优化下慢sql

不是cpu消耗高，是磁盘读写高。删完了，没出现问题。 下次删除超百亿的数据再观察下

端口映射了吗? kubectl port-forward --address 0.0.0.0 svc/demo-tidb 20160:20160–namespace=tidb

看下granafa监控的tikv-detail-Thread CPU-Unified read pool CPU 高不高

我是limit 10000 ,使用的主键id删除的

[image] 这个dashboard中sql语句平均ru是怎么计算的，怎么那么大的数

开始300万 慢慢加到1000万，现在跑2亿

单表数据量太少了吧没触发自动analyze [image]

怎么这么多字段数据是null

公有云使用简单方便，阿里云的本地盘性能不输物理机。