2节点RF=2集群删除数据重现测试的相关疑问咨询

测试环境与操作步骤 #

• 集群配置：2节点，复制因子（RF）=2
• 操作流程：
  1. 修改表的gc_grace_seconds参数为180s
  2. 统计初始表行数：共8行
  3. 关闭node2节点
  4. 在node1节点删除4行数据
  5. 等待180s后执行表压缩操作
  6. 重启node2节点，统计行数：node2为8行，node1为4行
  7. 执行全量修复命令：nodetool repair -full
  8. 检查各节点行数：均为4行

异常现象与疑问 #

根据官方文档预期，node2重启后删除的数据应重现，但执行全量修复后数据消失。1小时后，node1行数变为8行、node2为0行，再次执行全量修复后两节点均为8行，删除的数据重现。现针对以下问题解答：

1. 本次测试是否可视为成功复现删除数据重现问题？ #

是。测试最终出现了删除数据回滚至原始状态的现象，符合Cassandra中因tombstone生命周期、修复逻辑与压缩交互导致的数据重现场景，属于典型的删除数据重现问题。

2. 为何node2重启后删除数据未立即重现？ #

核心原因是数据版本优先级与修复逻辑：

• node2离线期间，node1执行删除操作生成的tombstone（墓碑标记）未同步到node2，因此node2重启后仍保留原始8行数据。
• 执行nodetool repair -full时，Cassandra以数据时间戳的先后作为同步依据：node1的删除操作时间戳晚于node2的原始数据，因此修复过程中node2的旧数据被node1的tombstone覆盖，导致node2行数降至4行。
• 你预期的“node1行数增至8行”是旧数据覆盖新删除操作的场景，这种情况仅当旧数据时间戳晚于tombstone时才会发生——本次测试中删除操作的时间戳更新，所以修复时优先保留了带删除标记的状态。

3. 为何最终删除数据在1小时后重现？ #

关键在于tombstone被垃圾回收（GC）清理，旧数据失去删除约束：

• 虽然你在gc_grace_seconds（180s）后执行了压缩，但node1的tombstone可能未被立即彻底清理。1小时后，tombstone已被GC完全移除，此时node1中不再有标记这些数据为已删除的记录。
• 同时，node2可能仍保留了原始8行数据的旧SSTable文件（未被压缩彻底清理）。当再次执行全量修复时，集群中存在“无删除标记的旧数据”和“已删除的当前状态”，由于tombstone已消失，Cassandra同步时会将旧数据重新引入，最终导致两节点都回到8行的原始状态。

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