你的 K8S 集群版本足够新的话是不需要 tidb 的 scheduler 的，https://docs.pingcap.com/zh/tidb-in-kubernetes/stable/tidb-scheduler#tidb-scheduler-扩展调度器 已经不建议部署了。通过改 helm 的参数可以不部署 scheduler

字段类型是否被修改过？ 可以用date函数试试？ select * from xxx where date(expire_date) = ‘2024-08-03’; 也可以用date 判断数据有没有时分秒？ select * from xxx where date(expire_date) = expire_date;

是的，本来是为了节省 MySQL 里的空间，对字段做了压缩处理存进了新字段，老字段没用了要删掉，同步到 TiDB 来了。有什么办法方便的重建表吗？类似 MySQL Optimize table 之类的？

我在一台 TiKV 上做了 compact，稍微腾出来了一些空间，但感觉应该是没有真的把 drop 列空出来的资源释放，和 MySQL 里对比不成比例。

./tikv-ctl --host localhost:20160 compact -c write -d kv --bottommost force 我尝试在节点上执行这个，现在还在跑，似乎硬盘在逐渐释放，我再观察一段时间

什么叫标记了？ ALTER TABLE 已经做完了，表里删掉的字段已经看不到了。

show global status; Ssl_cipher Ssl_cipher_list Ssl_server_not_after Ssl_server_not_before Ssl_verify_mode 0 Ssl_version Uptime 2428564 ddl_schema_version 3000 server_id 251d80aa-383c-4eee-9325-ba6ea85846ba tidb_gc_last_run_time 20240826-16:12:06.258 +0800 tidb_gc_leader_desc host:bigdata-tidb…

我已经在 github 开了 PR 做了修复 https://github.com/pingcap/dm/pull/1748

我清理的是旧的 v1.0 时候的数据，直接 rm 的，旧版本的所有硬盘上的东西其实都已经没有用了。 升级是在同一台机器上，在不同的目录部署的。把低版本的进程都停了之后手动在高版本的dm上启动task

对 我当然是开了 relay_log 然后看监控的，不开的话监控里这个指标是没数据的，有数据就说明开了。现在的问题是这个指标并不更新，不体现真实的硬盘容量。 我刚才将三个开了 relay 的实例中的一个 stop 再 start relay，硬盘指标更新了。 [image] 我手动用 curl 读监控指标也是启动时候的硬盘容量。 [image] 但我再次清理出一些容量，指标并不会更新。 [image] [image] 感觉就是这个指标采集有问题，或者就是这个指标的刷新需要一段时间，但实际上经过昨天一夜这个指标也没有变化。

应该相当于是一个全新的部署，之前是v1.0的dm，tiup 直接部署到新的实例上之后手动迁移了一遍 task。 我明天试一下重启 relay log