从Cassandra 1.0.12升级至1.1.0迁移SSTables时触发异常求助

从Cassandra 1.0.x跨版本升级到1.1.x时，SSTables格式迁移确实是最容易出问题的环节之一，结合你描述的场景，我来分享下排查和解决的常见思路：

• 严格遵循滚动升级流程，先处理单节点SSTables再启动服务
  1.0到1.1的SSTables存储格式有较大变更，必须在节点停服状态下用官方工具完成迁移，不能直接启动新版本服务。正确的单节点操作步骤应该是：

  1. 停止旧版本Cassandra服务：sudo service cassandra stop（根据你的部署方式调整命令）
  2. 替换为1.1.0的安装包及合并后的配置文件（你已经完成这步，没问题）
  3. 运行1.1.0自带的sstableupgrade工具处理SSTables：

     # 处理所有keyspace的所有表
     ./bin/sstableupgrade -a
     # 或指定单个keyspace
     ./bin/sstableupgrade my_keyspace
     # 或指定单个表（适合大集群分批处理）
     ./bin/sstableupgrade my_keyspace.my_table
     

  4. 确认迁移完成后，再启动1.1.0版本的Cassandra服务。如果之前跳过了sstableupgrade直接启动服务，大概率会触发迁移异常。

• 检查SSTables文件的权限问题
  升级后新的Cassandra进程可能对旧版本的SSTables文件没有读写权限，导致无法读取或修改文件。可以通过以下命令验证：

  ls -l /var/lib/cassandra/data/<你的keyspace>/<你的表>
  

  确保文件的所有者和组是Cassandra运行用户（通常为cassandra:cassandra），如果权限不符，执行以下命令修正：

  sudo chown -R cassandra:cassandra /var/lib/cassandra/data
  

• 查看日志定位具体异常原因
  直接查看Cassandra的系统日志（默认路径/var/log/cassandra/system.log），搜索包含SSTableMigration、CorruptedSSTable或IOException的条目：

  比如日志中出现Corrupted SSTable: /var/lib/cassandra/data/my_keyspace/my_table/aa-1-big-Data.db，说明该SSTable文件损坏
  遇到损坏的SSTable时，因为你已经做了备份，可以先将损坏的文件（包括对应的Index.db、Filter.db等附属文件）移到临时备份目录，再重新运行sstableupgrade或启动服务。

• 验证内存配置是否合理
  1.1.x版本对内存的需求比1.0.x略高，你调整的MAX_HEAP_SIZE建议不要超过物理内存的50%（比如8G内存的节点，堆内存设为4G左右），Xss（线程栈大小）建议设置为256k或512k。如果内存配置不合理，可能会触发OOM或线程栈溢出，间接导致SSTables迁移失败。

• 异常节点回滚与集群一致性修复
  如果滚动升级到某个节点时出现无法解决的异常，建议先回滚该节点到1.0.12版本（使用备份的安装包和配置），启动后运行nodetool repair修复该节点与集群的数据一致性，待集群状态正常后，再重新尝试升级该节点。

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