先说个开头。前阵子在运维交流群里看到有人问“Redis 5.x 直接下载 7.2 的二进制覆盖上去然后把老配置指过去能行吗”这个问题一下子把我拉回几年前我第一次给线上 Redis 升级的场景——当时我也是这么想的结果差点在启动阶段翻车。Redis 升级这件事表面看就是换个二进制、把配置指一下实际牵涉到配置指令变化、数据文件格式、复制协议、ACL 机制、内存淘汰策略等多个层面任何一个环节没照顾好都可能让业务流量砸在手里。这篇我把自己做 Linux 上 Redis 升级的完整思路、实操过程和踩坑记录写下来从版本评估、路线选择、配置迁移到数据兼容、主从切换、验证回滚一条线捋清楚。不管你是第一次升级还是已经升过几轮希望这篇能帮你少交一点学费。1. 升级决策背后这次升级到底要解决什么问题动手之前先别急着下载安装包。Redis 版本升级不是一个单纯“更新软件”的动作它本质上是把整个运行环境从一个定义好的语义区间挪到另一个区间。很多老实例已经跑了四五年从 3.x、4.x 一路用到现在的都有不同大版本之间的运行模型差异比很多人想象中要大。我见过不少团队升级 Redis 的理由是“别人都升了我们也该升了”这种理由往往带来最惨烈的翻车。我建议你先想清楚这三点第一你是被安全漏洞逼着升的还是想要新功能还是遇到了性能瓶颈。被安全问题逼着升那没得选但升级计划就要更保守优先挑补丁版本里改动小的路线想要新功能比如 Stream、ACL、多线程 IO、客户端缓存这些那就要接受大版本跳跃带来的配置和数据格式变化如果是性能瓶颈你是想解决大 Key 的延迟、内存碎片还是连接数打满不同诉求对应的升级重点完全不同。第二你现在用的版本距离目标版本隔了几代。从 5.x 升到 6.x改动相对温和很多老配置还能被兼容读取但从 4.x 甚至 3.x 直接跳到 7.x就是另一个量级的事了。中间经历了 RDB 格式的内部调整、AOF 多文件结构、从 slave 到 replica 的术语替换、ACL 权限系统引入这些变化都会在升级时集中爆发。第三你的 Redis 是纯粹缓存还是承担了持久化存储的角色。如果只是缓存丢了重建还能接受升级窗口和风险都好控制如果业务数据都在 Redis 里比如会话、排行榜、分布式锁状态那数据文件的兼容性、回滚方案就必须提前设计这不是改个配置就能糊弄过去的。另外升级目标版本的选择也要讲究。目前生产环境主流在 6.x 和 7.x其中 7.x 的稳定性已经过市场验证。我个人的习惯是不追最新大版本的首个 minor至少要等 x.2 之后的版本再考虑生产。比如当时 7.0 刚出的时候我先在测试环境观察等 7.2 出来以后才敢放到线上。宁可目标版本比你心里的期望低一个 minor也不要拿生产环境做小白鼠。2. 动手前先把版本和家底盘清楚决定了要升下一步不是装包而是把现状完整摸一遍。这一步做扎实了后面出问题才有底。我一般会把下面几个信息全部记录下来存成一个文本文件升级完再对照。版本相关的命令很简单但别只用一个最好交叉确认redis-server -v redis-cli -v redis-cli INFO server | grep -E redis_version|redis_git_sha1|run_id注意服务器上可能不只有一套 Redis。因为历史原因有些机器上/usr/bin/redis-server、/usr/local/bin/redis-server、源码目录里的src/redis-server可能版本都不一样。我之前就遇到过这种情况systemd 里写的是 A 路径实际拉起来的是 B 二进制排查问题时看的是 C 版本三个人三个版本乱成一锅粥。所以请用which redis-server、redis-server -v和systemctl status redis里的 ExecStart 路径三者对齐确保你摸到的是真实在跑的那一套。接着盘点配置和数据的分布。一次完整的盘点至少要覆盖以下内容配置文件路径及最后修改时间 数据目录位置及大小 日志文件路径 PID 文件路径 systemd unit 或 init 脚本内容 bgsave / AOF 重写的完整周期 maxmemory 和淘汰策略 持久化开启情况RDB、AOF、RDB-AOF 混用数据目录大小尤其要提前看du -sh /var/lib/redis、df -h /var/lib/redis这两条命令先跑一下。原因后面会讲升级前备份数据目录空间不够的话备份会失败而很多人恰恰会忽略磁盘空间这个前提。我记得有一次帮朋友升级他自信满满地说“数据目录就几个 G”结果du -sh一查是 87G磁盘剩余空间只有 60G。他没做预检直接BGSAVE完就打算拷贝数据结果写完备份文件磁盘满了Redis 自己也跟着被拖到近乎假死。这个教训很实在预检不是走过场每一项都可能变成拦路虎。在备份这一步我推荐直接复制整个数据目录而不是只拷贝dump.rdb或 AOF 文件。原因是升级过程中如果出现意外你需要的不是一个能加载的文件而是一个完整可回滚的状态。备份命令大概长这样# 先触发一次 RDB确保持久化文件是新鲜的 redis-cli BGSAVE sleep 3 redis-cli INFO persistence | grep rdb_last_bgsave_status # 保险起见用 cp -a 保留目录权限 cp -a /var/lib/redis /backup/redis-data-backup-$(date %F)拷贝之后记得做一次完整性校验用redis-check-rdb跑一下备份出来的 RDB 文件redis-check-rdb /backup/redis-data-backup-$(date %F)/dump.rdb如果开了 AOF也顺手用redis-check-aof校验。这一步能在升级开始前就发现问题而不是等出事以后再来复盘“当时备份的文件竟然是坏的”。提示复制数据目录时尽量先停写或错峰操作。如果实例在持续写入直接cp目录会导致文件处于不一致状态里面既有旧 RDB 又有正在写的 AOF所以备份后一定要用 Redis 自带工具校验别嫌麻烦。版本盘点清单里还有一个容易被忽略的项目客户端那边有没有依赖旧协议、旧命令的代码。比如老客户端用的是SLAVEOF或旧的AUTH流程升级后虽然多数还兼容但如果有客户端库版本特别老可能在新版本上连握手都失败。升级前最好也把客户端连接池的版本、连接参数扫一遍不要等上线了才发现客户端连不上。3. 三条升级路线最终我选了哪条Linux 上给 Redis 升级常见的有三条路用发行版自带的包管理器升级、编译源码安装、用官方镜像做容器化迁移。这三条路各有各的适用场景不能一拍脑袋选。我整理了一个对比表方便你根据自己环境来判断路线优点缺点适合场景包管理器升级操作简单依赖处理自动完成systemd 服务一般也会跟着更新版本由发行版仓库决定可能跨大版本过多仓库里的 Redis 常比官方滞后容易覆盖你手工改过的配置测试环境、非核心缓存业务源码编译安装版本完全可控可以精确到 patch 版本编译参数可定制不依赖系统仓库节奏需要编译工具链升级过程手工步骤多容易漏掉动态链接库或 systemd 配置生产环境核心 Redis尤其定制过内存分配器或需要特定版本容器化迁移环境隔离升级启动即一致性验证横向扩缩容方便可快速回滚到旧镜像需要 Docker 运行时网络和持久化模式要重新设计对已有非容器体系改造大新部署、已经容器化、想借升级同时完成迁移我个人的经验是生产环境核心 Redis 优先走源码编译路线原因就一条可控。发行版仓库版本滞后且更新策略不由你定Docker 路线如果底子不是容器体系硬迁移容易在权限、网络、持久化三个地方连环踩雷。而源码编译虽然手工步骤多但每一步都是自己执行的出问题了也知道从哪查起。源码编译的流程大致是# 下载目标版本的源码 tar 包并校验 sha256 wget https://download.redis.io/releases/redis-7.2.4.tar.gz sha256sum redis-7.2.4.tar.gz # 解压编译编译前先装好 gcc、make、tcl tar xzf redis-7.2.4.tar.gz cd redis-7.2.4 make distclean 2/dev/null # 如果目录之前编译过先清理 make -j$(nproc) make install编译完成后不要急着覆盖现有二进制。我先动一个小动作检查新二进制是否能正常加载旧配置。这一步能滤掉一多半配置不兼容问题方法也很简单# 用 6380 端口做冒烟测试不加 --daemonize直接把日志打到终端看 redis-server /path/to/old/redis.conf --port 6380 --daemonize no如果配置里有不认识的指令前台启动会直接红字报错。在真正替换旧服务之前用这个方式把配置问题先暴露出来是非常有效的分流手段。我多次遇到同事一上来就直接把旧配置指向新二进制然后 systemd 启动失败再回来慢慢调配置文件中间业务中断好几个小时其实提前用新端口试一下就完全能避免。这里再补几个源码编译的细节。第一新版 Redis 默认用 jemalloc 内存分配器如果系统里没有依赖库可能要提前安装第二make install安装出来的二进制默认在/usr/local/bin如果你的旧服务用的是/usr/bin/redis-server别忘了确认 PATH 顺序或者直接用绝对路径替换不然会“升级了个寂寞”第三如果有编译报错先看是不是缺了依赖比如 OpenSSL 的 dev 包生产环境一般都能很快补上别慌。如果你是走 systemd 管理的老实例替换二进制后还要再确认一下 unit 文件里的路径是否对应到了新二进制。我之前就见过有人源码编译安装了新版本结果 systemd 的 ExecStart 仍然指向旧路径重启之后 Redis 还是旧版本业务方却说“升级没用”其实是升级根本没生效。4. 配置文件迁移踩坑最集中的地方Redis 升级翻车最高发的区域不是数据文件而是配置文件。为什么因为旧配置文件里的指令新版本未必认识。Redis 对配置文件的处理是“一条一条读遇到不认识的就报 FATAL CONFIG FILE ERROR”这意味着一个指令就足以让整个服务起不来。最稳妥的做法不是拿旧配置直接启动新版而是以新版带的一份默认配置为底稿把旧配置里自定义过的项一条条平移过去。平移过程中真正坑人的是那些改过名的指令和换了新用法的参数。我列几个高频变化的都是实战中集中踩过的地方slaveof → 推荐改用 replicaof老写法新版还认但会提示 deprecated slave-read-only → replica-read-only hash-max-ziplist-entries → hash-max-listpack-entriesziplist 系列 7.x 下直接报错 hash-max-ziplist-value → hash-max-listpack-value list-max-ziplist-size → list-max-listpack-size zset-max-ziplist-entries → zset-max-listpack-entries用表格看更直观旧配置升级前新配置7.x说明slaveofreplicaof旧写法仍兼容但建议迁移slave-read-onlyreplica-read-only同上hash-max-ziplist-entrieshash-max-listpack-entries7.x 不认识旧名会直接拒绝启动zset-max-ziplist-entrieszset-max-listpack-entries同上list-max-ziplist-sizelist-max-listpack-size同上no-appendfsync-on-rewrite仍在但语义要注意拉高版本前确认配置值仍是理解的那个requirepassrequirepass仍可用但更推荐 ACL6.x 起 ACL 是主流这里要特别提醒“新版还认识旧指令”和“新版完全支持旧指令语义”是两回事。比如maxmemory-policy里的某个策略名配置名没变但底层实现换了遇到极端内存压力时的表现可能和以前不同又比如save的默认值不同版本可能不一样旧配置里没显式写save的升级后等于吃了新默认值RDB 落盘节奏和以前完全不同一旦实例重启你会惊讶地发现数据比预期丢得多。实操中我迁移配置的流程是这样先把旧配置里所有非默认项找出来redis-cli CONFIG GET *导出当前运行时参数或者直接挨个看配置文件里的有效行。找到新版自带的默认配置示例通常是源码里的redis.conf。打开旧配置逐行过判断每一条在新版本里是否依然有效、是否改过名、是否换了默认值。把自定义项写进新配置并顺手在行尾加注释说明这个参数是从旧配置哪一行带来的。用新二进制、新配置、新端口做一次性冒烟测试确认日志干干净净再动正式端口。如果你嫌逐行比对太费劲可以偷个懒把旧配置里所有#注释行和空行过滤掉得到有效指令集合再和目标版本默认配置的有效指令集合做差异比较快速定位“旧配置有、新配置不认识”的指令。这种方法不是 100% 准确但能快速缩小排查范围。# 去掉注释和空行提取有效配置行做对比 grep -vE ^\s*#|^\s*$ /etc/redis/redis.conf.old /tmp/old-effective.conf grep -vE ^\s*#|^\s*$ /path/to/redis.conf /tmp/new-effective.conf diff /tmp/old-effective.conf /tmp/new-effective.conf配置文件里还有一个非常容易被忽视的细节dir参数。新版 Redis 对数据目录的权限和使用方式和旧版没有本质区别但如果你从 5.x 跨到 7.xAOF 的内部结构已经变了启动后会生成额外的 manifest 文件如果dir指向的目录没有写权限启动到一半就失败日志里只会留下一句模糊的权限错误。我第一次给 7.0 做升级时就栽在这里排查了半天才发现是新版本要写appendonlydir目录旧目录里只给了redis用户对固定几个文件的写权限。最后再说一个看似不起眼其实很重要的点升级前对当前配置文件做一次保留副本。别小看这一步很多人改完配置就回不去了到时候想对照旧参数都无从下手。老配置文件路径上加上升级日期后缀比如/etc/redis/redis.conf.bak-2024-0521成本几乎为零收益可能是一个晚上的排查时间。5. 数据兼容性、主从顺序和回滚预案配置处理好之后真正的重头戏是数据侧。Redis 升级数据兼容性主要说三块RDB 文件、AOF 文件、复制链路。RDB 文件这一块简单说就是新版本可以加载旧版本的 RDB但旧版本不一定能加载新版本的 RDB。原因是新版 RDB 里可能包含旧版不认识的数据类型、模块数据、辅助字段。如果你已经用新版跑了一段时间再回滚到旧版旧版加载新版 RDB 文件时通常会报Cant handle RDB format version之类错误。所以在升级前我会强制要求先切主从主库跑的是新版本旧版本副本留一台作为快速回滚的“后手”而不是指望旧版能直接读取新版数据文件。AOF 这块要注意的是 7.x 引入了 multi-part AOF。老版本你可能只有一个appendonly.aof新版本启动后可能会生成appendonly.aof.manifest加 base/incr 文件。如果升级前没把目录结构和权限理顺新版本启动时会尝试做 AOF 的兼容转换转换失败就起不来。为了减少这个风险我通常的做法是在升级窗口内先停写或切流量做一次干净的 AOF 重写再切换二进制。主从顺序这是生产环境升级最讲究的部分。我最推荐的做法是“从库先行逐步切换”而不是直接对主库停服升级准备新二进制和配置先在从库机器上完成升级观察从库同步和负载情况至少一两个小时。确认从库没问题后把流量从主库切到新从库。常见方式是把原主库触发REPLICAOF操作让应用侧连接 VIP 切到新的主库也有的团队直接在客户端配置里切连接。原主库降级为新从库通过REPLICAOF指向新主库完成角色互换。最后把老主库也升级到新版本。这中间有一个关键点跨大版本之间不一定支持直接挂REPLICAOF。不同大版本的复制协议、offset 格式、内部状态可能不兼容直接挂会导致主从一直尝试全量同步却又失败。我见过有人从 5.x 直接拉一台 7.x 作为从库挂到老主库下结果日志里满是sync失败主库还因为反复需要全量同步把磁盘和带宽吃满了。所以跨大版本的主从级联最好先在测试环境复现一次确认同步正常再动生产链路。如果测试环境条件有限宁可先停机切换也不能冒险让主从去强拉。模块兼容这块如果实例加载了自定义模块比如某些厂商的模块或者社区模块升级前一定要确认模块版本是否支持目标 Redis 版本。Redis 的模块 API 在大版本间不是完全不变的新版本加载旧模块通常会报版本不匹配或直接加载失败。升级前先跑一遍redis-cli MODULE LIST把模块列表存下来然后去确认这些模块有没有对应新版本的 release。升级后加载模块如果报错第一时间别想着兼容直接找模块的新版本才是正路。回滚预案这块我的建议是宁可准备过头也不要准备不够。一个十五分钟能执行的回滚预案至少包含这几样东西旧版本二进制保留一份放到独立目录不依赖 PATH 环境 旧配置文件副本保留原来路径的备份 升级前的数据目录备份目录权限完整 systemd unit 或启动脚本的原版快照 回滚执行单停服 → 换二进制 → 换配置 → 换数据目录 → 启动 → 验证回滚操作要提前写成文档甚至脚本而不是临时靠记忆。真出故障的时候人的临时判断会被压力干扰照着写好的清单执行是最稳的。注意回滚只适合在升级初期发现问题时使用。如果新版本已经跑了很久新产生的数据远远超过了备份里的旧数据回滚就会丢失大规模增量数据这时候你就得权衡损失而不是机械执行回滚。这也是为什么我反复强调“从库先行、逐步切换”就是要把这个损失窗口压到最小。6. 升级后的验证清单一条条过服务起来了不等于升级就完成了。我认为完整的上线验证至少要跑完下面这一圈清单才算真正落袋。版本确认这是最基础的一条redis-server -v redis-cli -v redis-cli INFO server | grep redis_version然后看系统服务状态和开机自启systemctl status redis systemctl is-enabled redis如果 systemd unit 里写的是旧路径启动之后“看起来成功”实际拉起的还是旧版本这种假成功最迷惑人。日志检查直接过滤可疑关键字journalctl -u redis --since 30 minutes ago | grep -Ei fatal|error|assert|warn redis-cli INFO server | grep -E uptime_in_seconds|run_id重点看启动日志里有没有WARNING: The TCP backlog setting of 511 cannot be enforced、Cant handle RDB format version、FATAL CONFIG FILE ERROR这几种字样。内存和淘汰策略确认redis-cli CONFIG GET maxmemory redis-cli CONFIG GET maxmemory-policy redis-cli INFO memory | grep -E used_memory|used_memory_peak|mem_fragmentation_ratio升级后首次启动maxmemory如果因为配置没平移回到默认值那么当内存涨到系统物理内存上限前Redis 不会主动淘汰任何 key这往往是“升级之后内存直接打爆”的元凶。检查完这两项再盯着INFO memory里的mem_fragmentation_ratio观察一段时间正常值大概在 1.0 到 1.5 之间超过 2 就要注意碎片问题了。复制状态确认如果你还保留了从库redis-cli INFO replication | grep -E role|master_host|master_link_status|master_last_io_seconds_agomaster_link_status必须是upmaster_last_io_seconds_ago最好在几秒以内。如果这个数字持续增长说明主从连接或者复制流有阻塞。性能基线简单跑一下redis-benchmark -q -n 100000 -c 50 redis-cli --latency -c 100跑完基准之后再统计一段时间的INFO statsredis-cli INFO stats | grep -E instantaneous_ops_per_sec|total_commands_processed不需要追求基准测试数字比旧版高多少关键是和升级前留下的基线数据做对比。如果下降明显查慢日志和INFO commandstats看看是哪些命令变慢了是大 Key 影响了单线程还是配置项比如io-threads没调好导致副作用。持久化状态升级后主动触发一次重写确认不会出问题redis-cli BGSAVE redis-cli BGREWRITEAOF sleep 3 redis-cli INFO persistence看rdb_last_bgsave_status和aof_last_bgrewrite_status是不是ok。这一步非常推荐在新版本上主动做一次因为重写过程会完整读取数据目录下的所有文件很多文件级问题只有在重写时才会暴露。慢日志和监控接入升级后把SLOWLOG拉出来看看升级之后慢命令的分布有没有变化redis-cli SLOWLOG GET 10如果内部有监控系统把INFO里的used_memory、connected_clients、instantaneous_ops_per_sec、rdb_last_bgsave_status这几个指标重新接一遍。这一步很多人会丢但恰恰是最有用的升级后的一个小时内高频采样这些指标能在问题扩大前就发现苗头。7. 遇到故障时的排查姿势与十五分钟回滚假设你已经踩到了坑服务起不来、连接超时、内存异常别慌按顺序排查。第一类常见故障配置启动报错。日志里出现Bad directive、FATAL CONFIG FILE ERROR这种关键字不用怀疑基本就是配置文件里写着新版不认识的指令。先把日志里报错的指令行抄出来用redis-server --help或者新版示例配置文件确认这个指令的当前写法。第二类服务起来了但连不上。检查顺序是ss -lntp | grep 6379看端口有没有监听redis-cli PING看本机能不能通再redis-cli -h ip PING看远端通不通。如果本机能通远端不行八成是bind或protected-mode的问题。新版protected-mode默认是 yes如果你之前是拿老配置平移的这条可能没留意到结果外网访问直接拒绝。另外别忘了看防火墙规则这个和 Redis 升级没关系但排查时最容易被夹带私货。第三类systemd 服务反复拉起又退出。大概率是 unit 里的 ExecStart 路径指向了不存在的二进制或者新二进制的依赖库缺失。先systemctl cat redis看下 ExecStart再手动跑一次redis-server /path/to/conf前台启动把报错信息直接怼到屏幕上比翻 journal 日志更直接。第四类主从复制一直失败。日志里如果是SYNC反复失败大概率是跨大版本复制不兼容的问题。这种情况下别死磕按前面说的角色切换流程走或者从测试环境先确认兼容性。这些都没查出来的话就执行回滚预案。回滚的完整执行顺序我建议严格按固定节奏走1. 停服systemctl stop redis 2. 备份新版实例的数据目录记住现状防止回滚后还想留现场 3. 恢复旧二进制把旧目录里的 redis-server 和 redis-cli 放回原路径 4. 恢复旧配置文件到原路径 5. 恢复旧数据目录到原路径注意目录权限归属 6. systemctl start redis 7. redis-cli PING 验证看 INFO replication、INFO memory 8. 观察 10 到 15 分钟确认没有持续报错这里要特别提一点回滚时数据目录必须用升级前的备份不能用新版实例运行后生成的文件。因为新版可能已经在持久化文件里写入了新格式内容旧版读不了。回滚的代价就是这些时间的增量数据会丢这个窗口在升级前就必须和业务方确认好接受范围。我的经验是做好从库先行的切换式升级回滚场景极少会真正用到。因为主从切换本身就是天然的快速回滚手段新主有问题马上切回旧主。这比替换二进制回滚要快得多业务影响也小得多。所以如果你现在的环境允许搭主从我非常建议优先用主从切换来承载升级而不是只靠单机替换加回滚方案。回滚完成之后还要做事故复盘。不是写给人看的那种而是自己内心的清单配置差异、路径问题、权限问题哪一个环节可以提前用冒烟测试拦截。把每次升级踩的坑固化到下一次的检查项里这才是升级经验真正沉淀下来的地方。我自己后来做升级都会把“用新端口冒烟”“配置逐项 diff”“提前确认数据目录空间”“从库先行”这几条写进固定 checklist每次照着走翻车概率快速下降。最后再分享一个小习惯升级完成后我会把新配置文件里所有非默认项连同升级日期和原因一起提交到版本管理工具里。下次再有人问我“这台机器 Redis 是怎么配的”我不用翻机器直接看提交记录就全明白了。