长时间宕机的Cassandra 2.0节点如何安全重新加入集群？

最优方案选择 #

推荐选择先移除故障节点，再作为全新节点重新加入集群的方案，另外提到的replace_address替换自身的方案不建议使用，原因如下：

• replace_address的设计场景是替换完全无法恢复的故障节点，自身替换属于非官方支持的边界操作，Cassandra 2.0.17版本的该功能存在已知的未修复边界bug，宕机超gc_grace_seconds的场景下触发数据冲突的概率极高，无落地参考的前提下风险不可控
• 先移除再加新的方案流程有官方全版本支持，操作路径成熟，对集群的资源消耗可控，不会引入未知风险

直接运行nodetool repair不可行的原因 #

该操作风险极高，完全不推荐：

• 节点宕机2个月远超过默认10天的gc_grace_seconds阈值，宕机期间存活节点上已经清理了超过gc grace期的墓碑数据，直接启动故障节点后，节点上留存的2个月前的旧数据（包含已经被删除的记录）会被判定为有效数据扩散回集群，造成僵尸数据复活的严重业务问题
• 集群此前没有做过定期修复，各副本本身存在大量数据不一致，直接触发全量repair会占用极高的CPU、IO、带宽资源，对线上业务影响极大，且修复周期会长达数天甚至更久，效率远低于重新引导新节点的方案

最小影响操作步骤 #

1. 先在任意存活节点执行nodetool status，确认故障节点状态为DN，记录该节点的ID与IP地址
2. 选择集群内的一个存活种子节点，避开业务高峰执行nodetool removenode <故障节点ID>，该操作会自动将故障节点负责的token范围数据同步到其他存活副本
3. 执行nodetool removenode status确认移除任务完成后，再次执行nodetool status确认故障节点已从集群节点列表中消失
4. 清理更换硬盘后的故障节点的所有残留数据：清空data目录、commitlog目录、saved_caches目录下的全部文件，保证启动环境干净
5. 核对该节点的cassandra.yaml配置，确保cluster_name、种子节点列表、DC/rack配置、num_tokens配置与原有集群配置完全一致
6. 正常启动Cassandra服务，节点会自动以新节点身份执行bootstrap流程，从对应副本拉取它所负责token范围的全量数据，该过程默认不会占用业务读写请求的资源

过程监控与成功验证 #

执行过程监控 #

• 移除节点阶段：执行nodetool removenode status实时查看移除进度，观察存活节点的系统日志，确认无数据同步相关的ERROR级报错
• 新节点引导阶段：在新加入节点执行nodetool netstats查看数据同步进度，执行nodetool compactionstats查看数据合并任务进度，同时监控集群所有节点的CPU、IO、带宽占用，若负载过高可临时调整流式传输限流参数

最终成功验证 #

• 执行nodetool status确认新节点状态为UN（Up Normal），集群所有节点状态均正常
• 在新加入节点执行nodetool cleanup，清理不属于它负责的token范围的残留数据
• 在新加入节点执行nodetool repair -pr，做一次分区范围的增量修复，确认无数据一致性报错
• 执行nodetool describecluster确认集群状态正常，无不可达节点，可随机抽查业务表的读写请求验证数据正确性

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