Cassandra 3.11.x重启后rebuild命令从头执行问题求助

rebuild中断恢复的运行逻辑 #

Cassandra 3.11.x版本的rebuild断点续传能力依赖已同步token范围的持久化标记，正常运行逻辑如下：

1. 新节点启动rebuild后，首先计算自身负责的所有需要同步的token范围，过滤掉本地已存在有效数据的范围
2. 按顺序逐个从旧DC的对应副本节点拉取单范围的全量数据，完成写入、校验全流程后，将该范围标记为已同步，持久化到system.available_ranges系统表
3. 若rebuild中途中断，重启后新节点会优先读取system.available_ranges表的记录，直接跳过已完成同步的范围，仅同步未标记的范围

你遇到的全量重传问题通常由两种情况触发：

• 所用3.11.x版本低于3.11.10，存在已知的rebuild进度读取缺陷，重启后不会识别系统表中已记录的完成范围，直接重新遍历所有token范围
• 中断发生时没有任何一个完整的token范围完成全流程同步，system.available_ranges表没有写入任何有效记录，重启后只能从头开始同步

重传问题的解决方案 #

• 优先升级小版本：如果当前集群版本低于3.11.10，先将集群升级到3.11.x最新稳定版，该版本已修复rebuild进度丢失的已知问题，确保已完成的token范围可以被正确识别跳过
• 拆分token范围分批同步：不要执行全量rebuild，按小范围分批同步，命令格式为nodetool rebuild -src <旧DC名称> -ts <起始token>,<结束token>，单批同步的数据量控制在1-2小时可完成的大小，就算中途中断也只会重传当前正在同步的小范围数据
• 限制同步带宽降低旧DC负载：执行rebuild时添加限流参数，避免旧DC节点带宽、IO占满触发GC停顿，命令示例：nodetool rebuild -src <旧DC名称> --stream-throughput 50MB/s，可根据旧DC的空闲带宽调整数值
• 优化旧DC GC配置：同步前临时调整旧DC节点的JVM参数，将CMS回收器替换为G1GC，设置-XX:MaxGCPauseMillis=500，同时调低concurrent_reads、concurrent_writes参数，降低同步过程中的CPU和IO负载，减少长时间GC停顿的概率
• 临时关闭流校验降低开销：如果集群数据可靠性有保障，同步启动新节点时添加参数-Dcassandra.streaming.skip_checksum_validation=true，减少同步过程中的校验计算开销，同步完成后移除参数重启节点即可

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