Cassandra 历史stale数据删除方案咨询及操作疑问求助

方案二（新表替换旧表）疑问解答 #

1. 承载实时数据更新的表如何执行重命名操作 #

首先明确一个核心前提：Cassandra 3.0及以上版本已经完全禁用了ALTER TABLE ... RENAME TO重命名表的语法，即使是早期支持该语法的版本，重命名属于DDL操作，执行期间会短暂阻塞表的所有读写请求，完全不适合承载实时流量的生产环境使用。
如果一定要走新老表切换的逻辑，正确的无停服流程如下：

• 预先创建和旧表结构完全一致、已配置100天TTL规则的新表
• 调整业务服务的写逻辑，开启双写：所有新增数据同时写入旧表和新表
• 持续双写至少100天，直到新表中所有数据都符合100天保留的要求，不存在更早的过期数据
• 将读流量逐步切到新表，确认读写无异常后，下线旧表的双写逻辑，最终执行删除旧表的操作

2. Cassandra表操作底层逻辑与集群同步规则 #

首先要纠正一个操作误区：Cassandra的所有DDL操作（建表、删表、修改表结构等）都是集群级别的，你在任意一个节点提交合法的DDL请求，都会通过Gossip协议同步到集群内所有节点，不存在「仅在单节点创建/修改表」的情况。
如果按你假设的非正常操作场景（比如离线修改单节点schema再上线），会触发集群的schema冲突校验机制，集群会自动协商出统一的最新schema，冲突的错误schema会被直接覆盖：

• 如果你通过正常流程提交删除旧表的DDL请求，所有节点上的旧表对应SSTable数据文件会被标记为待删除，在下次compaction执行时会被彻底清除，不会出现旧数据反向同步的问题
• 如果你手动修改单节点的表结构/数据文件，会导致严重的schema冲突、数据不一致，甚至触发节点宕机，绝对禁止这类操作

更推荐的过期数据清理方案 #

你提到的两种方案中，Spark批量删除的可行性更高，但要注意控制删除速度避免产生大量墓碑压垮集群，同时还有更轻量的方案可选：

• 优先推荐按时间分区直接删除SSTable：如果你的表分区键带时间维度（比如按天作为分区键前缀），可以直接定位到所有超过100天的分区对应的SSTable文件，滚动停节点删除对应文件后再启动即可，整个过程速度最快，不会产生任何墓碑
• 如果没有按时间做分区，可以用Spark Cassandra Connector批量扫描旧数据，分小批次删除，每批次删除后预留足够的时间让集群消化墓碑，避免读写请求超时
• 如果表数据量很小，可以直接用cqlsh的COPY命令导出100天内的有效数据，执行TRUNCATE清空旧表后再把有效数据导回，操作最简单

内容的提问来源于stack exchange，提问作者Radhika