Cassandra新节点加入卡住，集群有节点磁盘满宕机的问题及方案咨询

问题1：宕机DN节点是否会影响新节点完成Bootstrapping？ #

会产生直接影响，核心原因如下：

• 新节点Bootstrap过程需要拉取自身负责Token范围对应的所有副本数据，若宕机节点是该部分数据的必要副本（比如副本数为2时其中一个副本宕机，或剩余副本无法覆盖全部待拉取数据范围），会导致数据拉取流程卡住，让新节点长期处于joining状态
• 若集群开启了Bootstrap阶段的数据一致性校验，宕机节点不可用会导致校验流程无法完成，直接中断Bootstrap进程

问题2：可立即执行的宕机节点磁盘空间恢复方案 #

有三类无风险的快速释放空间方案，优先级从高到低：

• 首先清理冗余非数据文件：删除节点上积压的Cassandra运行日志、GC日志、审计日志，若开启了commitlog归档，可删除已经完成归档的旧commitlog文件，这类文件删除不会影响Cassandra启动
• 调整文件系统预留空间：ext4等文件系统默认会预留5%的磁盘空间给root用户，可执行tune2fs -m 2 /dev/<磁盘设备名>将预留占比下调到2%，可快速释放数GB到数十GB的空间，足够支撑Cassandra启动
• 临时移出冷SSTable：你提供的是完整的单组3.11版本SSTable文件（mc前缀），只要将同前缀的8个关联文件整体移动到节点外挂存储/其他空闲存储介质，即可快速释放对应空间（不要拆分移动单个SSTable组件文件，会导致SSTable损坏）

临时移出SSTable后再移回的方案可行性 #

该方案完全可行，操作流程如下：

1. 将整组同前缀的SSTable文件全部移动到外部存储，确认磁盘剩余空间大于5%后启动Cassandra服务
2. 服务启动成功、节点状态转为UN后，执行nodetool cleanup清理该节点上不属于自身负责Token范围的冗余数据，释放永久磁盘空间
3. 待磁盘空闲空间足够承载移出的SSTable后，将文件移回对应Keyspace的表目录下，执行nodetool refresh <keyspace名> <表名>即可加载这部分数据，无需重启服务
4. 全部操作完成后执行nodetool repair确保数据一致性即可

注意：当前阶段不要直接移除宕机DN节点，否则其余节点需要承接该节点的Token范围数据，会直接拉高其余节点的磁盘使用率，大概率引发更多节点宕机。待宕机节点恢复、集群所有节点状态转为UN后，再重启新节点重新触发Bootstrap流程即可。

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