正常，使用 delete 删了要的 GC 和底层 rocksdb compaction 的

我说没变更是指你集群是不是业务量很少，真的没啥变动，不过看你监控之前应该是又的，你还是哪里有问题导致 drainer 没数据，你再检查下吧

TiDB 正常写入，drainer 检查点正常推进，下游 kafka 没有数据，有没有可能你没变更呢，看看 drainer 监控的 Drainer Event

哪个 tidb 实例写 binlog 写不下去，它就会停止哪个，比如说集群都正常，突然有个 tidb 实例与所有 pump 节点的网络有问题了，这时候它要写 binlog 的话，写不下去就会崩溃，其他 tidb 实例不受影响。

1、13/16=0.8125，所以你的监控是怎么监控的，不是把 page/cache 也算进去了吧 2、Heap 部分只是通常软件中内存消耗比较大的部分，程序占用内存还有 Stack 等等其他部分 3、持续上涨问题，建议你再观察一段时间

那就已经丢了，之前的跳过的没写 binlog 的事务找不回来了，只能通过 tidb api 或者重启 tidb 实例的方式重新让 tidb 从现在时间点开始写 binlog

写不了了，binlog 跟 GC 逻辑没关系的，失败了就不行，看 binlog-error 的设置决定怎么办，可能是 skip-binlog ，可能是崩溃

TiDB 一般横向扩容，很少有纵向扩容的，当集中式用呢

如果是测试环境就重启 tidb 吧，这是最简单的方法。

建议关闭

已转发 [image]

[image] 挺好的，进入单个集群里的时候，有地方能显示集群名字就好了啊，不然集群多了不知道是哪个集群

看你导出的目的是什么了

这个限制了查询语句返回最大行数，默认值 18446744073709551615，这套集群被人修改了这个参数 https://docs.pingcap.com/zh/tidb/v7.5/system-variables/#sql_select_limit-span-classversion-mark从-v402-版本开始引入span

请执行以下查询 show variables like '%sql_select_limit%';

每个文件 5000 行数据怎么得出来的

你来的正是时候，看置顶链接：大家期待已久的挑战免费考证活动即将开启（7-9 月），可以开始攒积分了，今年你会来参加吗～

TiDB 的文档写的很详细，可以在这里搜索一下：https://docs.pingcap.com/zh/

盘不行，建议换好一些的盘，能用本地 nvme 磁盘最好