Linux Cassandra集群升级：滚动升级与零停机实践

一、Cassandra 升级原理与兼容性

1.1 滚动升级（Rolling Upgrade）原理

Cassandra 无主架构支持混合版本运行：

• 新版本节点加入集群（如扩容）
• 协议兼容：Gossip、Streaming、CQL协议向后兼容
• 数据格式：SSTable格式逐版本演进（需upgradesstables）

过程：

1. 一个一个节点停机、升级二进制、启动
2. 新节点bootstrap或replace加入
3. 全集群升级后，运行upgradesstables转换格式

零停机关键：RF≥3 + QUORUM一致性，确保升级中多数副本可用。

1.2 版本兼容矩阵（截至2026年1月）

• 小版本（5.0.1 → 5.0.6）：直接滚动，二进制替换
• 大版本（4.1 → 5.0）：官方支持在线滚动，但需注意SSTable格式（mc/mv新格式）
• 不支持跳重大版本（如3 → 5）

Java兼容：5.0要求Java 11/17（推荐17）

1.3 风险评估

• 低风险：小版本patch（bugfix）
• 中风险：minor（如5.0.0 → 5.0.6）
• 高风险：major（如4 → 5），新特性可能引入回归

生产建议：先读CHANGES.txt与release notes。

二、小版本滚动升级实战（5.0.x 内）

2.1 准备工作

1. 备份：全Snapshot + Incremental
2. 测试集群验证：相同配置升级，压测
3. 监控就绪：Grafana告警抑制升级窗口
4. 下载新版本：/opt/apache-cassandra-5.0.6-bin.tar.gz

2.2 单节点升级步骤

对每个节点顺序执行（建议一次1-3节点）：

1. nodetool drain # flush Memtable，停止写
2. systemctl stop cassandra
3. 备份旧二进制：mv /opt/cassandra /opt/cassandra-old
4. 解压新版本，软链 /opt/cassandra → 新目录
5. 对比配置文件（yaml/env），合并变更
6. systemctl start cassandra
7. 监控：nodetool status（新节点JOINING → NORMAL）
8. nodetool netstats 检查streaming

全集群后：

nodetool upgradesstables  # 转换SSTable格式（可选，小版本通常无需）

2.3 自动化脚本

#!/bin/bash
# upgrade_node.sh <host>

HOST=$1
NEW_TAR=/opt/apache-cassandra-5.0.6-bin.tar.gz

ssh $HOST << EOF
nodetool drain
systemctl stop cassandra
mv /opt/cassandra /opt/cassandra-$(date +%Y%m%d)
tar -xzf $NEW_TAR -C /opt
ln -sfn /opt/apache-cassandra-5.0.6 /opt/cassandra
systemctl start cassandra
EOF

# 监控
nodetool status

Ansible playbook更佳。

三、大版本升级实战（4.1 → 5.0）

3.1 特殊准备

• Java升级到17
• 配置变更：num_tokens降低（5.0推荐32）、memtable_allocation_type=offheap_objects
• 新特性测试：Trie Memtable、UCS

3.2 升级步骤（滚动）

相同小版本，但额外：

1. 升级后节点启动，可能日志警告旧格式SSTable
2. 全集群升级完成（混合运行期监控一致性）
3. 执行：

nodetool upgradesstables -a  # 全表升级格式（耗IO，夜间）

• 5.0新SSTable（Trie）不可降级

3.3 零停机保障

• 客户端驱动支持token aware + 降级一致性
• RF=3 + QUORUM：单节点升级不影响
• 流量切换：升级前drain，升级后验证

四、回滚方案

4.1 小版本回滚

• 保留旧二进制
• drain + stop + 切换软链 + start
• 若upgradesstables已跑：不可回（格式变更）

4.2 大版本回滚

• 高风险：5.0新格式不可读4.x
• 方案：从备份Snapshot + sstableloader重建旧版本集群
• 预防：升级前全备份

生产黄金法则：升级前必备份，可回滚窗口内禁upgradesstables。

五、常见升级问题排查

1. 节点无法加入 → 版本不兼容 → 检查CHANGES.txt协议变更
2. Streaming失败 → 新格式不兼容 → 先升级部分节点
3. 性能回归 → 新GC行为 → 调G1参数
4. upgradesstables卡住 → IO风暴 → 限速 + 分表
5. CQL不兼容 → 新保留字 → 应用调整

日志关键：grep "Upgrade" system.log

案例：

• 某公司4.1→5.0，upgradesstables后读延迟高 → Trie bloom filter调优，恢复
• 小版本patch，节点OOM → 新bug → 回滚旧版
• 跳版本升级失败 → 中间版本过渡