【 TiDB 使用环境】生产环境
【 TiDB 版本】v6.5.2
【复现路径】主备集群通过ticdc实现机房高可用
【遇到的问题：问题现象及影响】运行一段时间发现主集群体积不断增大，备集群保持稳定，导致只有200多G数据主机群达到了1T，备集群只有280G
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【附件：截图/日志/监控】
主库gc有推进吗？
看下监控TIDB=》gc面板运行正常吗
看一下GC的保留时间以及GC是否开启
先看看监控regions的数量是不是在一直增加
主机群的region一直在增加，备集群很稳定，不增加
主集群gc时间是使用的默认时间10min，这个gc时间应该是收到ticdc-server的gc参数控制吧，ticdc-server的gc-ttl时间设置的12h
主库gc有推进，但是不回收空间
“主机群达到了1T，备集群只有280G”
这差距太大，你们删除的数据量有多大？盘是tikv独享的吗，还是混和其他服务部署的。
我最终调整了"max-merge-region-size": 20 ->100,和"max-merge-region-keys": 200000->500000,并调低了merge 调度值（观察对查询有没有影响）。主集群空间和region开始慢慢回收，最终从1.25T降到300G，基本和备集群持平。
我觉得tidb这俩参数是且的关系，即region size<=20M且keys <=200000才会触发相邻region合并，如果region大于20MB，且经过大量delete操作后keys数量无论多少（当然大于0个）都不会merge回收，造成空洞。不知道这块逻辑能不能调整调整，还是我理解的有问题，欢迎大佬们交流
主集群查下regions到底哪个对象占用了，我遇到表分析历史数据占用几百G的问题，sql如下
select DB_NAME,TABLE_NAME,sum(APPROXIMATE_SIZE) from
(
select t.DB_NAME,t.TABLE_NAME,region_id,t.APPROXIMATE_SIZE from information_schema.TIKV_REGION_STATUS t
group by t.DB_NAMe,t.TABLE_NAME,region_id,t.APPROXIMATE_SIZE
) a
group by DB_NAME,TABLE_NAME
order by 3 desc
2个参数是且的关系，另外merge-schedule-limit默认是8已经很保守，不需要调低。
一般来说数据都没有那种需要调参数优化的场景，先看看数据占用情况
业务每天都删除，前期删的会多一些；tikv是独享的
你这边最后咋处理了，分析的历史数据也会暂存在表里吗
tidb_enable_historical_stats参数改成off,6.5版本应该默认off，7.5是on很坑，然后truncate mysql.stats_history
delete 理论上虽然不是释放硬盘空间，但是gc以后也是可以复用的，不应该一直膨胀
我记得TICDC启动后会修改TIDB的TTL时间，防止GC把数据给清理了，你查一下