Cassandra v4修复后T1目录仍为空，为何需重启服务才生效？

核心原因在于Cassandra运行时的内存元数据与磁盘状态不同步，具体可拆解为以下几点： #

• 内存元数据未同步磁盘变化：Cassandra启动时会将所有表的结构、本地副本状态等元数据加载到内存缓存。当你直接删除Node1上T1的目录文件后，运行中的节点并不会自动感知到磁盘上的这个变动——内存里依然保留着「T1表本地副本存在」的记录，导致后续的nodetool repair无法识别到本地数据缺失，自然不会触发数据同步。

• 修复操作依赖初始加载的副本状态：nodetool repair执行时，会先基于内存中的元数据判断本地副本是否需要修复。如果内存里标记T1的本地副本「已存在」（哪怕磁盘上是空的），修复流程会认为本地数据是完整的，跳过从其他DC拉取数据的步骤。只有重启节点后，Cassandra会重新扫描磁盘上的表目录，发现T1目录为空，才会将本地副本状态更新为「缺失」，此时执行修复才会触发从其他DC的副本同步数据，生成SSTables文件。

• 分区范围缓存的影响：节点启动时会加载自己负责的分区范围信息，当磁盘上的表文件被删除后，内存中缓存的分区范围与实际磁盘数据不匹配，修复操作无法正确定位需要同步的分区数据。重启后节点重新加载分区范围与表的关联信息，修复才能正常拉取并写入数据。

结合你的场景来看，每个DC的副本因子为1，DC1的Node1的T1数据需要从其他DC的节点同步，而只有通过重启让节点重新识别本地数据缺失的状态，修复流程才会启动这个跨DC的数据同步动作。

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