★ FEATURED ARTICLE 接手过Linux服务器的人都知道Redis这玩意儿虽然稳定但也不是装完就万事大吉。版本迭代带来的安全漏洞、新数据结构、性能优化、集群协议调整都在提醒我们Redis升级这件事迟早要面对。我最近刚把一套运行了两年多的Redis 5.x集群逐步升级到7.0分支整个过程踩了不少坑也总结出一套在Linux上做Redis升级的完整打法。这篇文章不是官方文档翻译而是我实际执行过、验证过的步骤和判断逻辑适合正在规划升级、又怕搞挂线上缓存的小伙伴参考。Redis升级最怕的不是操作复杂而是“不知道风险在哪里”。很多同学以为下载个新版本覆盖旧二进制就完事了结果启动时报错、数据读不出来、主从直接断连最后狼狈回滚。所以我想先聊聊升级前必须想明白的几件事再给出一套可以直接照搬的实操流程最后把我在升级过程中遇到过的几个高频问题整理成排查实录。相信不管是第一次升级还是已经升级过多次的人都能从里面找到有用的东西。1. 升级前必须想清楚的三件事1.1 先搞清楚当前Redis版本和部署形态在动任何升级操作之前第一件事不是下载新版本而是把当前环境摸清楚。打开终端先跑几个命令redis-server --version redis-cli --version redis-cli INFO server输出里会看到redis_version、redis_mode、os、process_id这些信息。注意redis-server和redis-cli的版本可能不一样这个后面会专门说。同时要看下Redis的启动方式是用systemd管理还是直接daemonize启动还是通过脚本启动。这决定了你升级后应该怎么拉起服务。然后再确认部署形态。是单机、主从复制、哨兵模式还是Redis Cluster如果只是单机升级压力相对小如果是主从或集群就需要考虑升级顺序和故障转移时机。我当时那套是3主3从的集群又套了一层哨兵升级时就不能简单粗暴地一台一台重启。先梳理拓扑最好画一张简单的节点关系表标注每个节点的角色、配置文件路径、数据文件目录、监听端口。否则升级到一半自己都分不清哪个节点是主风险就大了。1.2 版本跨度决定了升级策略Redis的版本号遵循主版本.次版本.修订号。如果你从5.x升到6.x或者从6.x升到7.x属于跨大版本升级很多行为可能会变。Redis官方在发布说明里会列Breaking Changes但是很多人不看或者看了没往心里去。以我实际感受为例5.x到6.x最大的变化是引入了ACL权限控制、新版客户端缓存、多线程I/O默认关闭并且一些命令的行为做了调整。6.x到7.x变化更大新增了Listpack编码、AOF文件格式优化、shard命令、子命令权限控制等还有部分淘汰策略的细节变更。升级跨度越大兼容性风险越高。如果你当前是5.0.3这种老修订号想直接升到7.2.x一键切换的风险相当大。一个稳妥的思路是“大版本逐级升”比如5.0→6.0→6.2→7.0→7.2每升一级验证一遍数据和行为。当然如果只是同主版本内的小版本升级比如6.2.7升到6.2.14那风险小很多可以当作常规补丁处理。这一点务必在升级计划里写清楚。1.3 梳理数据持久化与高可用现状升级要求必须保证数据安全所以启动升级前先检查持久化配置redis-cli CONFIG GET save redis-cli CONFIG GET appendonly redis-cli CONFIG GET appendfsync redis-cli CONFIG GET dir redis-cli CONFIG GET dbfilename看清楚了RDB和AOF分别开没开文件放在哪个目录。如果appendonly开着还要检查AOF重写机制因为升级后新版本加载AOF时如果格式不兼容启动可能直接失败。RDB文件也是同理好在Redis官方承诺RDB格式在向后兼容上做得比较稳但风险不是零。另外确认一下线上是否还有写入流量。如果业务一直在写升级过程中不可避免会产生新数据这就不能只靠停服备份还要规划好如何保证增量数据不丢。对于高可用环境通常做法是先升级从节点再手动触发故障转移让新版本从节点变成主节点然后再升级旧主节点。整个过程要让业务无感知客户端通过哨兵感知主节点切换。如果只是单机那就需要规划一个维护窗口停写、备份、升级、启动、校验。2. 升级方案选型四条路怎么选2.1 系统包管理器升级最省事但版本受限在CentOS上用yum、Ubuntu上用apt直接执行升级是很多人的第一反应# CentOS/RHEL yum update redis # Ubuntu/Debian apt update apt upgrade redis这种方式优点是省心不用手动处理依赖systemd单元文件也会被自动更新。但缺点也很明显系统自带软件源里的Redis版本通常比较旧比如CentOS内置源可能还停在6.2甚至5.x。不同的第三方源维护节奏不一如果直接把源切换到别的第三方仓库又可能引入别的依赖冲突。还有一个容易踩的坑系统包管理器升级时有时会直接覆盖原有的配置文件或者把新版本里已经变掉的配置指令带进来导致Redis启动失败。所以我个人的习惯是只在测试环境用包管理器升级生产环境还是走官方二进制手切路线至少可控性更强。2.2 官方二进制包手动替换生产环境首选所谓官方二进制包就是官方编译好的release tarball。下载后解压里面包含redis-server、redis-cli、redis-check-rdb、redis-sentinel等可执行文件。这个方案的优点在于版本选择灵活想固定在6.2.14还是7.2.4自己说了算。目标路径可控随便放哪都行用软链切版本很方便。回滚简单旧版本的二进制保留着出问题就切回去。缺点是需要自己处理初始化脚本、systemd unit和配置文件路径。但这些都不是问题只要你提前把配置备份好按模板改改就行。绝大多数生产环境都应该选这条线。安装时一般这样处理mkdir -p /opt/redis tar xzf redis-7.2.4.tar.gz -C /opt/redis ln -s /opt/redis/redis-7.2.4 /opt/redis/current export PATH/opt/redis/current/src:$PATH当然你也可以直接把旧的redis-server替换掉但我更推荐用软链加版本目录的方式升级前ci就是一个ln -s切换出问题再切回去。2.3 源码编译适合有特殊编译参数需求如果你对Redis的运行环境有特殊要求比如要带TLS、要启用jemalloc之外的内存分配器、要嵌入某些patch那就只能走源码编译yum install -y gcc make tar cd /download tar xzf redis-7.2.4.tar.gz cd redis-7.2.4 make BUILD_TLSyes MALLOCjemalloc make install PREFIX/opt/redis/redis-7.2.4源码编译的坑主要是两个。第一编译依赖不满足比如缺gcc或者make版本太老编译过程中报错。第二编译时用的优化选项和当前系统内核/glibc版本不匹配可能导致运行时性能异常。编译本身不难但如果你没有特殊需求纯属折腾。我见过有人为了升级而升级非要编译一遍结果生产上用了一个自己编译的版本出了问题都不知道该怪谁。所以建议默认用官方二进制特殊需求再编译。2.4 容器化升级简单但别忽略数据卷现在用Docker跑Redis也很常见。容器升级通常就是替换镜像tagdocker pull redis:7.2.4 docker run -d --name redis-new -v /data/redis:/data -p 6379:6379 redis:7.2.4但容器升级真正的风险不在镜像而在数据卷。如果你把Redis数据目录挂载到宿主机务必确认新旧容器挂载的路径一致并且数据卷里不能有旧容器运行时的锁文件或socket残留。另外容器镜像里的Redis配置往往是最小化配置很多参数要自己通过命令行或挂载配置文件放进去。如果这两个环节没对齐启动是很顺利但数据文件可能加载不到甚至数据目录权限错乱导致Redis没法写。容器升级前先把旧容器的停止流程做干净再启动新容器。3. 手把手实操官方二进制包升级全流程3.1 备份与安全快照宁可多备份不可存侥幸无论选哪个方案升级前第一操作永远是备份。Redis本身提供了两条持久化路径RDB快照和AOF日志。先触发一次手动快照redis-cli BGSAVE然后确认RDB文件已经生成查看lastsave时间戳redis-cli LASTSAVE如果开启了AOF可以在低峰期执行一次AOF重写把所有数据整理成最新的AOF文件redis-cli BGREWRITEAOF备份时不仅要把数据文件带出来配置文件也要带。一般来说Redis的数据目录和配置目录是分开的但很多人会把config文件和data文件放在同一个目录下。先通过redis-cli CONFIG GET dir确认数据目录再记录配置文件路径。执行备份mkdir -p /backup/redis-$(date %Y%m%d%H%M) cp /etc/redis/redis.conf /backup/redis-$(date %Y%m%d%H%M)/ cp /data/redis/dump.rdb /backup/redis-$(date %Y%m%d%H%M)/ cp -r /data/redis/appendonlydir /backup/redis-$(date %Y%m%d%H%M)/ 2/dev/null || true备份完成后不要急着升级。先在测试机上用备份文件启动新版本Redis验证能正常加载数据再上生产。这一步能过滤掉90%的兼容性问题。我在实际升级中曾经因为AOF文件里残留了旧版本某个命令的写法新版本直接拒绝加载如果在生产上才发现就晚了。3.2 下载新版本二进制并校验完整性官方发布页会提供tar.gz文件和支持校验的SHA256值。你可以用curl或wget下载cd /download wget 官方下载地址的压缩包下载后先校验哈希sha256sum redis-7.2.4.tar.gz将校验输出和官方页面上的SHA256值比对一致再解压。这一步很多人忽略但在供应链安全越来越被重视的今天养成校验习惯是必要的。解压后用redis-server --version确认版本tar xzf redis-7.2.4.tar.gz cd redis-7.2.4 src/./redis-server --version此时你看到的是新版本能正常运行的证据。接下来把二进制安装到目标目录并切换软链。3.3 配置迁移与兼容性检查配置迁移是升级中最容易出错的一环。新版Redis往往弃用或改名了一些配置项直接把旧配置丢给新版本可能在启动阶段就报unknown directive或者bad argument。我的建议是分三步走把旧配置逐项和新版本默认配置对比。新版发布包里通常会带一份redis.conf模板你可以diff /etc/redis/redis.conf /opt/redis/current/redis.conf找出已废弃的配置指令逐个确认替代方案。比如旧版里maxmemory-policy这个配置在部分大版本中检查更严格指定的淘汰策略字符串必须和枚举完全一致rename-command的格式也有变化。每个变化都对应一个潜在启动风险。准备好新配置文件后先做一个最小启动测试redis-server /etc/redis/redis.conf --port 6390 --daemonize no使用一个临时端口启动观察日志输出有没有error或warning。如果启动正常连接上去检查一下redis-cli -p 6390 INFO server然后执行SHUTDOWN NOSAVE关闭临时实例。确认无误后再用正式端口启动。注意千万不要在生产上用临时端口和正式数据目录做实验因为两个实例会同时操作同一份RDB/AOF轻则锁冲突重则数据错乱。最好先把数据目录复制一份用作测试。3.4 启动验证与数据完整性检查正式切换时先停掉旧实例。如果你用systemdsystemctl stop redis如果之前是裸启动就用redis-cli SHUTDOWN正常关闭。等进程退出后确认端口释放ss -lntp | grep 6379接下来把当前软链切到新版本ln -sfn /opt/redis/redis-7.2.4 /opt/redis/current然后启动新实例systemctl start redis启动后重点检查几项redis-cli INFO server redis-cli INFO persistence redis-cli DBSIZE看版本号是否为预期版本看持久化状态是否正常看key数量是否和升级前一致。如果DBSIZE相差很大先不要慌检查一下是否用了多个逻辑数据库SELECT之后逐一比对。还可以抽几个key做类型和TTL检查redis-cli --bigkeys redis-cli RANDOMKEY--bigkeys是扫描大key的也能间接验证key是否都能扫描出来。对于主从或集群还要检查复制偏移量。主节点上执行redis-cli INFO replication观察master_repl_offset从节点上观察slave_repl_offset应该接近或一致。如果有多个从节点每个都要看一遍别只盯着主节点。3.5 回滚预案的执行细节一定要提前写好回滚文档不然真出问题的时候手忙脚乱。回滚的基本思路是保留旧版本二进制和旧配置新版本启动后如果发现异常立刻关闭新版本换回旧二进制用旧配置启动加载旧数据。但有一个很隐蔽的坑新版本首次启动时可能会在退出前自动触发AOF重写或RDB保存从而覆盖了旧版本格式的数据文件。如果没做物理备份回滚后旧版本可能因为加载不了新格式的数据文件而起不来。所以我每次升级前除了常规备份还会额外复制一份dump.rdb和AOF目录绝对不修改它作为回滚保险。回滚具体命令systemctl stop redis ln -sfn /opt/redis/redis-6.2.14 /opt/redis/current systemctl start redis redis-cli -p 6379 INFO server回滚后同样要验证数据量和客户端访问。如果你已经发生了AOF重写那就只能把备份的AOF文件先恢复回去再启动旧版本。因此备份时不只拷贝文件还要记录备份文件的属主和权限回滚时全部还原。4. 升级后的常见问题与排查实录4.1 redis-server和redis-cli版本不一致当我第一次升级完执行redis-cli --version发现显示的竟然是旧版本而redis-server --version已经是新版本。原因很简单redis-cli和redis-server的PATH来源不同。可能缓存了旧路径也可能有两个安装位置。排查方式which redis-server which redis-cli如果分别指向不同目录改动/usr/local/bin下的软链或者在当前用户.bashrc里把新版本bin目录放到PATH最前面。不要小看这个现象版本不一致可能导致CLI连接新server时某些命令行为有差异尤其涉及INFO输出字段时很容易误判。4.2 配置指令不兼容导致启动失败升级后最常见的启动错误就是# Fatal error, cant open config file # Bad directive or wrong number of arguments这时不要急着改配置先把日志拉出来journalctl -u redis -n 50 --no-pager或者直接看Redis日志文件。遇到unknown directive在新版配置模板里搜一下这个指令是不是改名了。比如旧配置里可能写了appendonly yes新版本对AOF文件的组织形式做了调整appenddirname成为新指令那么需要额外指定目录。绝大多数问题都能在官方release notes里找到解释但实际排查时更快的办法是临时注释掉出问题的指令让服务先起来再逐一调整。但注意注释配置前要备份原文件别把可用配置搞乱。4.3 数据文件加载失败或权限异常有次升级后Redis启动时一直打印Cant open the append log file。检查后发现是Appendonly目录的属主不对旧版本启动用户是redis新版本却用了root启动导致Redis没权限写AOF文件。这种情况在二进制手动替换时特别容易踩到。解决办法是统一启动用户chown -R redis:redis /data/redis chown -R redis:redis /etc/redis然后重启。另外新版本对数据文件的校验更严格如果旧RDB文件有逻辑问题加载时可能直接拒绝。可以先运行自带的检查工具redis-check-rdb /path/to/dump.rdb redis-check-aof /path/to/appendonly.aof根据输出判断是文件损坏还是版本不兼容。如果AOF文件存在末尾截断有些版本会提示unexpected end of file这时候不要轻易用redis-server --appendonly yes启动因为它可能尝试恢复更安全的做法是先修复AOF再启动。4.4 高可用环境下主从切换引发的风险集群升级顺序没规划好最容易出大问题。我自己就见过一次先升级了主节点从节点还是旧版客户端协议结果主节点升级后下发了新版本才有的复制命令从节点直接报unknown command复制中断。所以主从/集群环境升级必须遵守“先从后主”的原则。具体步骤是先升级所有从节点确认从节点日志显示和主节点连接正常、复制偏移量连续。利用哨兵或手动方式把原主节点降级为从节点redis-cli -p 6379 REPLICAOF 新主节点IP 端口验证新主节点可写客户端能正常切换。升级旧主节点再把它重新加入集群让它从新主节点同步数据。升级过程中还要注意哨兵本身也要升级因为不同版本哨兵协议的细节可能有微调。如果旧哨兵还在监控新主节点它可能误判主节点故障造成不必要的切换。所以最好先把哨兵升级并检查监控状态再动数据节点。4.5 升级后性能下降或延迟升高版本升级后性能变差也是有人碰到过的。不要慌先量化问题。用redis-cli --latency观察延迟分布用INFO commandstats看最耗时的命令再用INFO memory看内存碎片率。新版Redis对某些数据结构的编码有调整比如Hash、Zset可能在特定大小下使用listpack或新的紧凑编码读写时多了一层转换开销。这种情况下可以把hash-max-listpack-entries、set-max-intset-entries等参数调大或调小匹配你的数据特征。还有一点容易被忽略新版默认启用active-defrag的行为可能和旧版不同导致内存碎片率波动进而影响性能。可以在redis.conf中显式设置activedefrag yes或no并观察内存碎片率。性能问题不是看一眼就能定位的需要用监控工具对比升级前后的指标如果手头有Prometheus/Grafana那最直观。5. 几次升级后我养成的操作习惯5.1 每次升级前都做一次“预演恢复”现在不管版本跨度多小我都会在测试环境走一遍完整流程停服、备份、换二进制、启动、对比数据、回滚。看起来很花时间实际上一次预演只要几十分钟却能提前发现配置兼容问题、存量数据异常、甚至MISCONF错误。预演时连客户端访问权限、连接数限制、慢查询日志配置都要保持一致这样测试结果才可信。我甚至会故意在预演中制造一次“加载失败”强制自己演练回滚回滚熟了真出事的时候才不会慌。5.2 升级后的观察周期不能太短升级完成不代表结束。我一般把升级后的前24小时当作重点观察期。每5分钟记录一次内存、连接数、命令耗时、持久化状态观察是否有间歇性错误。不要只盯主节点从节点和哨兵的日志也要看。如果业务有定期任务比如凌晨做全量导出要特别关注凌晨的日志因为数据量一上来很多问题才暴露。5.3 重大升级的黄金法则把风险控制在可回滚的边界内总结成一句话就是永远不要让自己陷入“只能一条道走到黑”的局面。升级前先想回滚切换前先想备份版本跨度大就分步走。Redis作为一个底层组件它的升级其实没那么可怕可怕的是轻视它。只要我们把升级当成一次有预案的常规变更而不是一次“看脸”的赌博操作起来就会从容很多。希望这篇文章能帮你把Redis升级踩过的坑都提前躲开。
阅读完成 · 觉得有帮助？
