ScyllaDB 2026.x 到 2026.3 滚动升级与回滚完全指南【免费下载链接】scylladbNoSQL data store using the Seastar framework, compatible with Apache Cassandra and Amazon DynamoDB项目地址: https://gitcode.com/GitHub_Trending/sc/scylladb本篇技术指南面向 ScyllaDB 运维与 DBA 人员完整讲解将集群从 ScyllaDB 2026.x 滚动升级到 2026.3 的标准化流程以及升级失败时回滚到 2026.x 的操作步骤。指南覆盖 Red Hat Enterprise LinuxRHEL、CentOS、Debian、Ubuntu 以及 EC2/GCP/Azure 云镜像环境读完本文你将掌握升级前检查与数据备份、单节点串行升级的全部命令、升级成功验证方法以及严格受限的回滚前置条件与执行细节。该指南以 docs/upgrade/upgrade-guides/upgrade-guide-from-2026.x-to-2026.3/upgrade-guide-from-2026.x-to-2026.3.rst 为权威依据并可在 升级指南索引 中与其他版本升级指南对照查阅同目录下的 2026.x 补丁升级指南 则适用于同版本线内的小版本升级。升级前的准备工作在动手升级任何节点之前需要先完成三项检查确保客户端、监控体系与目标版本三者协调一致1. 升级你的驱动Driver如果你在使用 ScyllaDB 官方驱动访问集群请先于 ScyllaDB 服务器完成驱动升级。官方支持每个驱动的最新两个版本驱动版本过旧可能无法与新版 ScyllaDB 的协议与行为兼容导致应用侧异常。2. 升级 ScyllaDB 监控栈Monitoring Stack若你部署了 ScyllaDB Monitoring Stack请核对当前监控栈版本是否支持你将要升级到的 ScyllaDB 版本可参考官方监控栈的支持矩阵。官方建议直接升级到最新版本的监控栈以免旧版监控的指标采集或面板渲染与新版节点不兼容。3. 查看特性更新Release Notes升级前应通读 ScyllaDB 官方发布的 Release Notes确认 2026.3 引入的新特性、行为变更与已知问题特别是会影响滚动升级的兼容性变更。滚动升级的核心原则串行、无需全集群停机ScyllaDB 的版本升级采用滚动rolling方式不需要将整个集群停机。操作方式是对集群中的每个节点**逐一串行**执行以下完整步骤检查集群 schema 是否同步Drain 该节点并备份数据备份配置文件停止 ScyllaDB下载并安装新版 ScyllaDB 软件包启动 ScyllaDB验证升级成功警告必须严格串行执行。不要在前一个节点验证通过并正常运行新版本之前就着手升级下一个节点。在滚动升级期间官方强烈建议不要使用 2026.3 的新特性避免引入跨版本状态不一致不要执行管理类操作如 repair、refresh、rebuild、增删节点等如使用 ScyllaDB Manager可先暂停其计划中或正在运行的 repair 任务不要做 schema 变更。这一约束的根源在于滚动升级的中间态中集群内同时存在 2026.x 与 2026.3 节点任何依赖新版本能力的状态写入都可能破坏跨节点一致性从而阻塞后续节点的升级。升级步骤详解第一步检查集群 schema 同步升级前必须确认所有节点 schema 一致。若节点间存在 schema disagreement升级流程将失败。nodetool describecluster从源码实现看nodetool describecluster在 ScyllaDB 中并不是原生工具而是通过 REST 客户端实现的见 tools/scylla-nodetool.cc它依次调用/storage_service/cluster_name、/snitch/name、/storage_service/partitioner_name等 REST 端点输出集群信息并调用/storage_proxy/schema_versions获取各节点 schema 版本。如果输出中所有 host 都归属于同一个 schema version说明集群 schema 已同步若出现多个 schema version需要先解决不一致再继续升级。第二步备份数据drain snapshot任何重大操作如升级之前都建议将全部数据备份到外部设备。官方推荐使用 ScyllaDB Manager 创建备份也可以使用nodetool snapshot手动备份。对集群中的每个节点执行nodetool drain nodetool snapshot执行后记下nodetool snapshot输出的快照目录名并将/var/lib/scylla下所有以该目录名命名的快照目录复制到外部备份设备。当所有节点都完成升级后用以下命令清理快照防止磁盘空间被占满nodetool clearsnapshot -t snapshot从源码看drain与snapshot同样是 REST 调用见 tools/scylla-nodetool.ccdrain_operation向/storage_service/drain发起 POSTsnapshot_operation向/storage_service/snapshots发起 POST见同文件 L2343 起clearsnapshot_operation则向/storage_service/snapshots发起 DELETE见 L562 起。快照是 SSTable 级别的文件拷贝不会影响线上服务是升级回滚最重要的数据兜底。第三步备份配置文件备份scylla.yaml配置文件以及 ScyllaDB 软件包以备需要回滚升级。配置文件是集群行为的核心例如 conf/scylla.yaml 中定义的cluster_name、num_tokens: 256、listen_address、rpc_address、endpoint_snitch等一旦丢失会直接影响节点重启与集群拓扑。Debian/Ubuntusudo cp -a /etc/scylla/scylla.yaml /etc/scylla/scylla.yaml.backup sudo cp /etc/apt/sources.list.d/scylla.list ~/scylla.list-backupRHEL/CentOSsudo cp -a /etc/scylla/scylla.yaml /etc/scylla/scylla.yaml.backup sudo cp /etc/yum.repos.d/scylla.repo ~/scylla.repo-backup备份软件源文件scylla.list/scylla.repo至关重要因为回滚时需要原样恢复 2026.x 的软件源才能重新安装旧版本软件包。第四步优雅停止节点sudo service scylla-server stop第五步下载并安装新版本安装前先用scylla --version确认当前运行的版本号并记录下来——这是回滚时判断哪些节点已升级、哪些节点未升级的依据。Debian/Ubuntu将 ScyllaDB 的 deb 软件源更新为 2026.3 对应的版本即把/etc/apt/sources.list.d/scylla.list指向 2026.3 官方软件源地址安装新版sudo apt-get clean all sudo apt-get update sudo apt-get dist-upgrade scylla过程中前两个提问均回答 y。RHEL/CentOS将 ScyllaDB 的 rpm 软件源更新为 2026.3 对应的版本即把/etc/yum.repos.d/scylla.repo指向 2026.3 官方软件源地址安装新版sudo yum clean all sudo yum update scylla\* -yEC2/GCP/Azure 云镜像如果使用官方 ScyllaDB 镜像推荐直接按上面Debian/Ubuntu的步骤升级即可如果使用自定义镜像并在其上安装了 Ubuntu/Debian 的 ScyllaDB 软件包则需要执行扩展升级流程# 1. 按 Debian/Ubuntu 步骤更新 deb 软件源 # 2. 安装新版 ScyllaDB并额外安装 scylla-machine-image 包 sudo apt-get clean all sudo apt-get update sudo apt-get dist-upgrade scylla sudo apt-get dist-upgrade scylla-machine-image # 3. 运行 scylla_setup但不要运行 io_setup # 跳过 io_setup 步骤 # 4. 运行云环境 IO 配置 sudo /opt/scylladb/scylla-machine-image/scylla_cloud_io_setup云镜像场景之所以要额外处理scylla-machine-image是因为该包承载了云环境特有的实例化与 IO 调优逻辑升级后必须重跑scylla_cloud_io_setup以匹配新版本在云磁盘上的 IO 配置。第六步启动节点sudo service scylla-server start第七步验证升级成功用nodetool status检查集群状态确保所有节点包括刚升级的节点都处于UNUp/Normal状态用 REST API 检查 ScyllaDB 版本确认与目标版本一致curl -X GET http://localhost:10000/storage_service/scylla_release_version该端点在 api/storage_service.cc 中实现直接返回scylla_version()nodetool status中的版本信息、以及scylla-housekeeping等后台脚本的版本判定见 dist/common/scripts/scylla-housekeeping也都依赖该 REST 端点 3. 检查 scylla-server 日志journalctl _COMMscylla与/var/log/syslog确认没有新增错误 4.两分钟后再次检查确认没有延迟暴露的问题。确认该节点升级成功后再转向集群中的下一个节点重复上述全部步骤。回滚流程Rollback回滚前置条件极其严格警告回滚流程仅当集群中还有节点未升级到 2026.3 时才能执行。一旦滚动升级的最后一个节点也以 2026.3 启动回滚即告不可能——此时唯一能恢复集群到 2026.x 的方式是从备份恢复整个集群。因此以下回滚流程只适用于从 2026.x 升级到 2026.3 尚未在所有节点完成即失败的情况只在已升级到 2026.3 的节点上执行回滚同样必须逐节点执行只有当前节点回滚成功后才能处理下一个节点。回滚同样是滚动过程不需要全集群停机。对每个要回滚到 2026.x 的节点依次执行drain 并停止 → 恢复旧软件包 → 恢复配置文件 → 重载 systemd → 启动 → 验证。回滚步骤一Drain 并优雅停止节点nodetool drain sudo service scylla-server stop关于drain需要补充说明从 service/storage_service.hh 的注释可以看到drain与正常的 shutdown hook 存在差异——drain 会先停止接收新的写请求、冲刷内存中的 memtable 到 SSTable并等待 in-flight 请求处理完毕保证停止后的节点数据完整落盘为回滚后的重启提供一致的数据视图。回滚步骤二恢复并安装旧版本Debian/Ubuntu# 1. 删除新版软件源文件 sudo rm -rf /etc/apt/sources.list.d/scylla.list # 2. 恢复升级时备份的 2026.x 软件源 sudo cp ~/scylla.list-backup /etc/apt/sources.list.d/scylla.list sudo chown root.root /etc/apt/sources.list.d/scylla.list sudo chmod 644 /etc/apt/sources.list.d/scylla.list # 3. 安装旧版本 sudo apt-get update sudo apt-get remove scylla\* -y sudo apt-get install scylla过程中前两个提问均回答 y。RHEL/CentOS# 1. 删除新版软件源文件 sudo rm -rf /etc/yum.repos.d/scylla.repo # 2. 恢复升级时备份的 2026.x 软件源 sudo cp ~/scylla.repo-backup /etc/yum.repos.d/scylla.repo sudo chown root.root /etc/yum.repos.d/scylla.repo sudo chmod 644 /etc/yum.repos.d/scylla.repo # 3. 安装旧版本 sudo yum clean all sudo yum remove scylla\* sudo yum install scyllaEC2/GCP/Azure 云镜像使用官方镜像时按Debian/Ubuntu的步骤回滚即可使用自定义镜像时需要额外恢复scylla-machine-image包# 1. 按 Debian/Ubuntu 步骤恢复 2026.x 软件包 # 2. 额外安装 sudo apt-get update sudo apt-get remove scylla\* -y sudo apt-get install scylla sudo apt-get install scylla-machine-image过程中前两个提问均回答 y。回滚步骤三恢复配置文件sudo rm -rf /etc/scylla/scylla.yaml sudo cp /etc/scylla/scylla.yaml-backup /etc/scylla/scylla.yaml这一步使用升级前备份的scylla.yaml.backup恢复 2026.x 时代的配置避免新版安装过程对配置文件的任何改写影响旧版本行为。回滚步骤四重载 systemd 配置如果 systemd 的 unit 文件在版本切换过程中发生了变化必须重载sudo systemctl daemon-reload回滚步骤五启动节点sudo service scylla-server start回滚步骤六验证回滚成功验证方式与升级验证完全相同见上文第七步验证升级成功用nodetool status确认所有节点处于UN状态、用curl -X GET http://localhost:10000/storage_service/scylla_release_version确认版本已回到 2026.x、并检查日志无新增错误。确认该节点回滚成功后再继续处理下一个节点。从源码理解为什么这些命令可靠本指南中的所有nodetool子命令在 ScyllaDB 中均为 REST API 客户端封装见 tools/scylla-nodetool.cc而非与 Cassandra 兼容的独立守护进程——这保证了它们与 ScyllaDB 服务端实现严格同源、语义一致。其中与升级/回滚流程直接相关的端点包括操作nodetool 子命令底层 REST 端点源码位置检查 schema 同步describecluster/storage_proxy/schema_versions等tools/scylla-nodetool.cc数据落盘drain/storage_service/drainPOSTtools/scylla-nodetool.cc创建快照snapshot/storage_service/snapshotsPOSTtools/scylla-nodetool.cc清理快照clearsnapshot/storage_service/snapshotsDELETEtools/scylla-nodetool.cc查看快照listsnapshots/storage_service/snapshotsGETtools/scylla-nodetool.cc版本校验无curl 直连/storage_service/scylla_release_versionGETapi/storage_service.cc另外需要留意drain与正常关机的行为不同见 service/storage_service.hh 的源码注释升级/回滚流程中先drain再stop的顺序正是为了在节点停止前完成所有写请求的冲刷与落盘这是滚动升级中保证数据一致性的关键一步。小结ScyllaDB 2026.x → 2026.3 的升级是一套标准化的滚动流程以串行为铁律每个节点经历 schema 检查 → 备份drain snapshot 配置→ 停止 → 换源安装 → 启动 → 验证六个阶段回滚则必须严格限定在集群尚有未升级节点的时间窗口内并逐节点恢复旧软件包、旧配置与 systemd 状态。把握好这些步骤与前置条件即可在保持集群在线的情况下安全完成版本迭代并在必要时全身而退。如需执行同一版本线内的小版本patch升级可参考同目录下的 2026.x.y → 2026.x.z 升级指南涉及指标项变更时还可查阅本文档同目录的 2026.x → 2026.3 指标更新说明。【免费下载链接】scylladbNoSQL data store using the Seastar framework, compatible with Apache Cassandra and Amazon DynamoDB项目地址: https://gitcode.com/GitHub_Trending/sc/scylladb创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考