一、ScyllaDB升级的核心痛点

1.1 滚动重启的本质

ScyllaDB是分布式数据库，升级时如果直接停服替换，会导致业务中断，所以常用滚动重启方式：每次只重启集群中的1到2个节点，等这些节点升级完成后，再重启其他节点，保证大部分节点正常提供服务。不过这个操作有个隐形问题：重启单个节点后，集群会自动触发数据重平衡——把这个节点上的数据分摊到其他节点，避免数据分布不均，这会占用大量服务器资源，同时如果重启的节点是新版本，其他旧版本节点可能和它不兼容。

1.2 sstable格式不兼容的风险

ScyllaDB用sstable格式存储数据，不同大版本的sstable格式不一样，就像旧版Word的文档不能直接用新版Office打开。如果升级时新旧版本混跑，旧节点读新节点的sstable会出错，新节点也可能无法同步旧节点的数据，轻则出现数据延迟，重则导致业务报错。我之前接触的某电商平台就踩过这个坑：没提前检查格式兼容性，滚动重启一个节点后，支付请求延迟直接涨了5倍，很多用户支付失败，后来花了2小时才回滚，损失不小。

二、滚动重启前必须做的准备工作

2.1 检查告警阈值是否合理

升级前要调整告警规则，避免误报打断升级流程，比如把磁盘使用率告警阈值从85%调到80%以下，请求延迟告警从1s调到1.5s以上，给升级过程留缓冲空间。这里给一个检查阈值的Shell脚本，注释清晰可直接用：

#!/bin/bash
# 检查ScyllaDB升级前的告警阈值是否适配维护场景
# 适用技术栈：Shell脚本+Prometheus告警规则配置

# 1. 定位ScyllaDB的告警规则文件路径（根据实际安装路径调整）
ALERT_RULE_FILE="/etc/scylla/conf/alert-rules.yml"
echo "当前告警规则文件路径：$ALERT_RULE_FILE"

# 2. 检查磁盘使用率告警阈值（核心指标）
DISK_THRESHOLD=$(grep -A6 "node_disk_usage" $ALERT_RULE_FILE | grep "threshold:" | awk '{print $2}')
echo "节点磁盘使用率告警阈值：${DISK_THRESHOLD}%"

# 3. 验证阈值是否符合升级要求（建议≤80%）
if [ $DISK_THRESHOLD -gt 80 ]; then
    echo "⚠️  警告：磁盘使用率告警阈值过高，升级期间磁盘占满会触发误报，建议调整到80%及以下"
else
    echo "✅  磁盘使用率告警阈值设置合理"
fi

# 4. 检查请求延迟告警阈值（次核心指标）
LATENCY_THRESHOLD=$(grep -A6 "request_latency_seconds" $ALERT_RULE_FILE | grep "threshold:" | awk '{print $2}')
echo "请求延迟告警阈值：${LATENCY_THRESHOLD}s"
if (( $(echo "$LATENCY_THRESHOLD > 1" | bc -l) )); then
    echo "✅  请求延迟告警阈值适配升级场景，升级期间不会误报"
else
    echo "⚠️  警告：请求延迟阈值过低，升级数据重平衡期间容易触发误报，建议调到1.5s以上"
fi

2.2 编写完善的回滚脚本

升级时如果出现数据异常或服务故障，要立刻回滚到旧版本，不能手动一个个操作，容易出错。下面是通用的ScyllaDB回滚Shell脚本，适配CentOS/RHEL系系统：

#!/bin/bash
# ScyllaDB升级回滚脚本，技术栈：Shell脚本
# 使用方法：./rollback.sh <旧版本号>，比如./rollback.sh 3.2.10

# 1. 检查是否传入了版本号参数
if [ -z "$1" ]; then
    echo "❌  错误：请指定要回滚的ScyllaDB版本号，示例：./rollback.sh 3.2.10"
    exit 1
fi
TARGET_VERSION=$1
echo "即将回滚到ScyllaDB版本：$TARGET_VERSION"

# 2. 停止当前运行的ScyllaDB服务（给节点10秒停止时间）
echo "正在停止当前ScyllaDB服务..."
systemctl stop scylla-server
sleep 10

# 3. 卸载当前版本，安装指定旧版本
echo "正在卸载当前版本..."
yum remove -y scylla-server scylla-tools --nogpgcheck
echo "正在安装指定版本：scylla-server-$TARGET_VERSION scylla-tools-$TARGET_VERSION"
yum install -y scylla-server-$TARGET_VERSION scylla-tools-$TARGET_VERSION --nogpgcheck

# 4. 启动服务并校验节点状态
echo "正在启动ScyllaDB服务..."
systemctl start scylla-server
sleep 30  # 等待服务初始化完成

# 5. 检查集群节点状态（正常状态显示为UN，即Up Normal）
nodetool status
echo "✅  回滚操作完成，请检查上述节点状态是否全部为UN"

2.3 确认并锁定维护窗口

升级必须选业务低峰时间，比如凌晨2点到4点，这个时间段用户请求最少，就算出现性能波动影响也最小，最好提前在业务系统里发公告，避免用户误以为服务故障。还要提前确认集群的节点数，比如10个节点的话，每次只能重启2个，不能同时重启超过3个，防止集群数据分布失衡。

三、滚动重启的实际操作步骤

3.1 分批重启节点的策略

重启时先选非核心节点，比如集群里的从节点，再选主节点，每次操作记录节点ID，避免漏重启或重复重启。比如集群节点是node1到node10，先重启node1、node2，等这两个节点升级完成，再重启node3、node4，以此类推，每次重启后都要等节点状态变成UN（正常在线）再操作下一个。

3.2 重启后的节点状态校验

每个节点重启后，用nodetool status命令看状态，如果是UN就正常，要是是DN（Down）或其他状态，要立刻排查：比如看节点日志/var/log/scylla/里有没有sstable格式错误的日志，确认是格式不兼容的话，赶紧执行回滚脚本，不要继续操作。

3.3 数据重平衡的观察与处理

重启节点后，集群会自动触发数据重平衡，这个过程会占用大量CPU和磁盘IO，要监控iostat看磁盘使用率，top看CPU使用率，如果超过阈值（比如磁盘IO使用率90%以上），要暂停重启其他节点，等当前重平衡完成后再继续，避免所有节点同时重平衡拖垮集群。

四、升级后的监控与异常处理

4.1 核心指标的持续监控

升级完成后的2小时内，要监控4个核心指标：

  1. 请求延迟：如果从原来的100ms涨到500ms以上，说明数据重平衡还在消耗资源，要给1天时间观察，不用立刻处理；
  2. 磁盘使用率：如果某节点磁盘使用率超过90%，说明数据重平衡没完成，要手动触发轻量重平衡（不要强制操作）；
  3. 错误率：看有没有数据读取失败的错误，有就查sstable格式日志；
  4. 节点状态：所有节点必须是UN状态，有离线的要立刻排查。

4.2 常见异常的快速处理

如果出现sstable格式不兼容导致的读错误，要立刻回滚到旧版本，不要尝试修复，因为ScyllaDB的格式兼容性要求非常严格，手动修复很容易丢数据；如果是数据重平衡慢，等2小时还没完成，可以重启所有重平衡中的节点，让集群重新触发轻量平衡，不要用强制平衡命令，会影响性能。

五、总结

ScyllaDB滚动升级的核心是“预检查、留缓冲、分批动、快回滚”，千万不能直接上线操作，提前1周就要准备好检查脚本和回滚脚本，选好维护窗口。之前的电商平台就是因为没做预检查，花了2小时回滚，损失了近10万营业额，所以一定要重视前置准备工作。对于分布式数据库来说，升级的稳定性比速度更重要，宁可多花1天准备，也不要冒业务中断的风险。