Cassandra3.9并行启动多修复会话后失败，咨询nodetool scrub操作注意事项

问题核心原因 #

你使用的Cassandra 3.9版本未包含对应修复补丁，误启动多并行修复会话后，SSTable上残留了内存级的修复中标记，导致新修复任务无法抢占资源，触发Cannot start multiple repair sessions over the same sstables报错。

nodetool scrub是不是唯一解决方案？ #

不是，scrub是高影响的最终兜底方案，优先尝试低风险操作即可解决问题：

• 第一步：在所有涉及报错的节点执行nodetool repair -stop，终止当前所有活跃的修复会话
• 第二步：如果终止后仍报错，滚动重启两个报错节点即可清除内存中残留的修复标记，无需修改磁盘数据，业务影响极小
• 仅在上述操作都无效的场景下，再选择执行scrub操作

生产环境执行scrub的注意事项 #

执行前准备 #

• 确认集群副本数RF≥3，且当前节点外至少有1个完整的副本数据可用，scrub会丢弃无法校验的损坏数据，需有副本兜底恢复
• 提前摘除该节点的业务流量，scrub是高IO、高CPU消耗的操作，执行期间节点无法正常响应业务请求
• 执行nodetool drain将节点内存中的所有数据刷写到磁盘，再停止Cassandra进程，避免内存数据丢失
• 备份当前节点目标keyspace（你场景中的test库）的所有SSTable文件，直接复制data目录下对应keyspace的文件夹到独立备份路径，操作出错可直接回滚

执行中注意 #

• 不要添加-s（跳过损坏数据）参数，默认模式下scrub遇到损坏数据会直接终止，不会自动丢弃数据，避免误丢数据
• 全程监控节点磁盘IO、CPU负载和scrub运行日志，遇到异常及时终止操作

执行后校验 #

• 启动Cassandra进程后，先单独针对该节点执行一次全量修复，确保数据和集群其他副本一致
• 验证目标表的读写功能正常，数据校验无误后，再将节点切回生产集群承接流量

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