Cassandra 3.11.10/11节点恢复后num_tokens异常变更问题咨询

• 版本默认配置差异：Cassandra 3.0.x版本默认num_tokens为256，3.11.x版本默认值调整为512，若升级时直接复用新版本默认cassandra.yaml，未显式配置num_tokens为256，首次启动时会将512的配置写入本地system.local系统表。
• 恢复操作覆盖系统表：你的恢复步骤没有过滤系统表，备份文件中如果包含了配置为512个token的system表数据，恢复后会覆盖本地系统表的配置，导致和当前cassandra.yaml中256的配置冲突。
• 配置未生效：检查cassandra.yaml中num_tokens配置是否被注释、是否存在重复配置项，若参数未正确生效，节点会默认使用3.11.x版本的512默认值。

根据你的集群实际配置，选择对应方案即可：

方案1：适配现有token配置（推荐集群统一配置时使用） #

如果集群其他节点均已调整为512个token，直接修改当前节点cassandra.yaml中num_tokens的值为512，重启节点即可正常启动。

方案2：重置本地系统表配置（推荐集群统一用256个token时使用） #

如果确认集群所有节点num_tokens均为256，可清理本地冲突的系统表记录，强制读取yaml配置：

1. 停止当前节点Cassandra服务
2. 删除本地system.local表数据：

rm -rf /var/lib/cassandra/data/system/local-*

3. 确认cassandra.yaml中num_tokens已显式取消注释，配置值为256
4. 重启Cassandra服务，节点会自动重建system.local表，读取256的配置加入集群

方案3：优化恢复流程避免复发 #

后续执行数据恢复时，过滤系统表仅恢复业务数据，避免系统表配置冲突，调整恢复命令如下：

find ${DATA_DIR} -mindepth 2 -path "*/snapshots/${BACKUP_NAME}/*" -not -path "*/system/*" -type f -exec bash -c 'dir={} && cd ${dir%/*} && mv {} ../..' \;

• 升级Cassandra版本时，不要直接替换为新版本默认配置文件，需要将旧版本中所有自定义配置（包括num_tokens、监听地址、RPC配置、副本策略等）同步到新版本cassandra.yaml中。
• 生产环境执行任何数据删除、恢复操作前，必须先全量备份当前节点的数据目录，避免误操作导致数据丢失。
• 多节点集群修改num_tokens配置前，必须保证所有节点配置一致，避免出现集群拓扑异常。

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