Cassandra清理过程中重索引出现Time out error超时错误如何处理

注意：普通读请求超时参数read_request_timeout不覆盖Cassandra内部索引重建的全表扫描、索引写入流程，这是调整后仍然报错的核心原因。

1 调整正确的超时参数 #

需要修改cassandra.yaml里的三类超时配置，调整完成后滚动重启集群节点生效：

• 范围查询超时range_request_timeout_in_ms：重索引依赖全表范围扫描，默认值10s，建议调整为30000（30s）以上，单表数据量超过100G可调整到60000（60s）
• 写入请求超时write_request_timeout_in_ms：索引重建会批量生成并写入索引数据，默认值2s，建议调整为20000（20s）以上
• 若通过nodetool rebuild_index触发重索引，还需要修改cassandra-env.sh里的RMI响应超时参数：-Dsun.rmi.transport.tcp.responseTimeout=180000，默认值60s，建议调整为180000（3min）以上

2 优化重索引执行逻辑 #

避免单次请求压力过大触发超时：

• 每次仅重建单个索引，不要批量操作：
  nodetool rebuild_index <你的Keyspace名称> <你的表名> <待重建的索引名>
• 大表场景按Token分段重建，拆分扫描范围：
  nodetool rebuild_index --start-token <起始Token> --end-token <结束Token> <你的Keyspace名称> <你的表名> <待重建的索引名>
• 重索引期间调低集群流式吞吐量阈值，避免占用过多集群资源：
  nodetool setstreamthroughput 16，单位为MB/s，可根据集群实际带宽调整数值

3 排查底层性能瓶颈 #

如果调整参数后仍超时，需要检查节点运行状态：

• 重索引期间监控节点磁盘IO、CPU负载，若磁盘IO使用率持续高于80%，需将重索引任务调整至业务低峰期执行
• 检查表的gc_grace_seconds配置，若参数值过大，重索引会扫描大量墓碑数据拖慢速度，可先执行nodetool compact清理无效墓碑后再重建索引

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