【 TiDB 使用环境】测试
【 TiDB 版本】v8.1.0
【复现路径】 配置tikv关闭压缩
【遇到的问题：问题现象及影响】1. 设置tikv配置项
[rocksdb.defaultcf]
compression-per-level = [“no”, “no”, “no”, “no”, “no”, “no”, “no”]
bottommost-level-compression = “disable”
然后对进群执行compact，发现tikv的used size从之前的300G扩大到2T，我的理解是数据解压缩后重新写下去了，这个时候下线一个tikv实例（原来是4个），发现数据迁移结束后，剩下的三个tikv实例的used size变成了2.1T，明显少于预期（应该是3T左右吧），怀疑新增加的region副本还是被压缩了，然后新增一个tikv实例后，观察到新增的tikv数据迁移完成后的used size是300G，证实了迁移过去的数据还是被压缩了，这是为什么？
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【附件：截图/日志/监控】
可能是TiKV 节点间压缩配置不一致，导致数据迁移到 “配置为压缩” 的节点时被重新压缩
要解决 TiKV 压缩配置不生效导致数据迁移后仍被压缩的问题，需从列族配置覆盖、节点配置一致性、Compact 操作范围 三方面排查
数据迁移时目标tikv实例仍按默认或残留压缩策略写入，是会导致新副本被压缩的。
通过tikv ctl命令执行default cf的compact（tikv-ctl --host ip:port compact -d kv未指定开始位置和结束位置），发现新上线的节点需要额外指定–bottommost force才能将迁移过来的压缩数据解压缩重新写入；而下线节点过程中，运行了一段时间的tikv节点，直接执行compact就能把迁移过来的压缩数据解压缩写下去
新实例上线时就指定了不压缩的配置，后期执行compact也能解压缩，感觉新实例一上线就没有默认配置了。还有我怎么去诊断残留压缩策略呢？这个现象确实是有点像哪里有老策略的残留