1. 升级前的准备工作先把风险想清楚再动手Redis 在 Linux 服务器上的升级是一件听起来简单、实操起来有很多细节的活儿。很多人以为就是下载新包、make install、重启服务就完事了结果要么启不来要么连不上更严重的直接把数据搞丢。我见过太多这种案例了所以先把升级前必须要做的准备工作讲清楚。先说一个最常见的误解Redis 版本之间虽然基础用法一致但内部协议、持久化文件格式、配置项语义都在慢慢变化。举个例子Redis 4.x 时代主从同步用的是 SYNC 命令从 6.0 开始默认用 PSYNC2如果主从节点之间版本差异过大同步就可能失败。又比如 RDB 文件的格式Redis 7.2 之后对某些内部编码做了调整旧版本读不了新文件的场景虽然少见但你在跨大版本升级的时候绝不能赌它一定兼容。所以我在做任何一次 Redis 升级之前会先列一个最小检查清单当前 Redis 版本是多少跑在什么 Linux 发行版上要升到哪个版本中间隔了几个大版本有没有做持久化用的是 RDB、AOF还是两者都开有没有主从架构、哨兵集群、Cluster 集群业务客户端用的什么语言底层连接库是什么版本是否存在对过时命令、旧配置项的依赖这个清单的价值在于它能让你在动手前就判断出升级路径是就地升级还是平滑迁移。如果只是小版本升级比如从 6.2.8 升到 6.2.14那基本可以就地更新数据文件也不用太担心兼容性。但如果是从 5.x 直接跳 7.x那就必须走迁移路线了后面我会详细展开。另一点容易被忽略的是升级之前必须确认服务器上的 gcc 版本。很多人下载了 Redis 6.2 或 7.0 的源码包编译时报错jemalloc相关、unknown type name‘adstest’ functions或者干脆报gcc: unrecognized command-line option其实就是编译器太老。Redis 从 6.0 开始对编译器和标准库有了更高要求建议 gcc 至少 8.x最好 9.x 以上。下面这个命令先跑一下gcc --version如果版本偏低优先用 yum 或 apt 升级工具链而不是硬着头皮去改编译参数那样会留下隐患。再说数据备份。有人会问Redis 不是自带 RDB 持久化吗我备份 dump.rdb 文件不就行了话是没错但你要注意备份的一致性。如果 Redis 还在运行直接拷贝 RDB 文件虽然大多数场景下也能用但它可能不是最新状态。更稳妥的做法是先触发一次BGSAVE等 RDB 快照完成后再把 dump.rdb 文件复制到目标机器或安全目录。AOF 模式的话也可以通过CONFIG REWRITE把当前配置落盘再备份 AOF 文件。我个人的习惯是导出当前配置、快照文件、AOF 文件三者都备份这样无论走哪条迁移路线都有底牌。还有一个很多人踩过的坑升级前没有检查现有 Redis 是否还在被高频写入。如果你在做 RDB 备份的同时线上业务还在大流量写入那备份出来的文件虽然能恢复但未必是最新的状态重启之后可能会丢一小段写入。所以如果条件允许最好在低峰期操作或者通过主从架构先摘除一台节点做升级演练验证没问题后再对主节点操作。2. 升级方案选型就地编译还是平滑迁移Redis 升级方案我把它分成三类同目录就地升级、新版本迁移升级、通过 Docker 容器迁移。每一类的适用场景不同不能一概而论。同目录就地升级适合小版本跨度、无架构变化、数据文件格式兼容的场景。操作就是备份原 Redis 二进制和配置文件下载新版本源码编译安装然后直接用原有配置启动。好处是快缺点是如果新版配置项有删改你需要手动排查 config 文件里的旧参数否则 Redis 可能启动时报Bad directive or wrong number of arguments。新版本迁移升级适合大版本跨越比如 4.x 升 6.x、6.x 升 7.x。这种方案的核心思路是新版本装到独立的目录旧实例继续跑先把全量数据导出再用新实例加载确认数据完整后再切换流量。这套流程虽然操作步骤多但安全系数最高出问题可以随时回滚。Docker 容器迁移是近几年很流行的方式特别是你已经有容器化运维习惯的前提下。它的好处是依赖环境隔离不用纠结宿主机的 gcc 版本和 library 兼容性升级就是换镜像重启容器回滚更是秒级操作。但也有注意点比如持久化文件的挂载位置、端口映射、容器内 Redis 的配置路径、日志收集方式这些如果不提前规划好上线后反而更麻烦。我个人在给公司服务器做 Redis 升级时采用的判断标准很简单小版本就近升级就地编译大版本跨越无条件走迁移方案如果是全新环境或者本来就有 Docker 基础设施直接容器化。下面我分别给出两条最常用的实操路线大家可以根据自己的场景选。2.1 就地升级小版本更新最快路径就地升级看起来简单但有几个细节必须落实到位。第一步先确认你的 Redis 安装路径和配置路径。很多人习惯用whereis redis-server、ps -ef | grep redis来找更方便的方式是redis-cli info server | grep -E executable|config_file|version你会看到类似这样的输出redis_version:6.2.8 executable:/usr/local/bin/redis-server config_file:/etc/redis/redis.conf记住这两个路径后面会用到。第二步备份数据和配置文件。我还是强烈建议你用原子性的方式备份redis-cli -a 你的密码 BGSAVE然后等redis-cli -a 你的密码 INFO persistence里的rdb_bgsave_in_progress变为 0再执行cp /var/lib/redis/dump.rdb /data/backup/redis/dump_$(date %F_%H%M%S).rdb cp /etc/redis/redis.conf /data/backup/redis/redis.conf.bak有 AOF 的话也一并备份。第三步下载新版本源码。以 Redis 6.2.14 为例cd /usr/local/src wget https://download.redis.io/releases/redis-6.2.14.tar.gz tar -zxvf redis-6.2.14.tar.gz cd redis-6.2.14注意不要用 6.2.14 里自带的安装路径覆盖旧版本先编译完再决定。第四步编译安装。我一般会先编译再验证二进制可用然后再替换。别直接make install那样会覆盖系统路径下的旧版本万一编译有问题连回滚都不方便。make -j$(nproc)编译完成后生成的二进制文件在src/目录下。先临时用它启动一个隔离端口验证比如 6380./src/redis-server --port 6380 --daemonize yes redis-cli -p 6380 ping正常情况下会返回PONG。确认新版本二进制没问题后再停掉测试实例替换正式二进制./src/redis-server --port 6380 shutdown cp src/redis-server /usr/local/bin/redis-server cp src/redis-cli /usr/local/bin/redis-cli cp src/redis-sentinel /usr/local/bin/redis-sentinel第五步用你原来的配置启动新版 Redis观察日志尤其是加载 RDB/AOF 的阶段有没有报错。如果启动没问题但发现某些配置项被忽略或者报错用redis-cli CONFIG GET *逐一核对。最后别忘了验证数据redis-cli -a 你的密码 DBSIZE对比升级前的 key 数量同时抽查关键 key 是否存在、类型是否正确。2.2 迁移升级大版本跨越的安全路线如果你是从 Redis 5.x 直接跳到 7.x我不建议就地升级原因是RDB 文件格式在不同大版本间虽然有兼容性设计但 Redis 官方并未承诺跨多代的强一致兼容5.x 到 7.x 之间很多命令的行为发生了变化比如CONFIG SET的某些参数、XINFO的字段格式、COMMAND命令的输出结构如果用旧客户端连新版本可能出现协议解析问题7.x 引入的新特性如Redis Functions、Sharded Pub/Sub、ACL 增强会改变你原本的运维模式不能指望原地替换就行。迁移升级的核心思路是挂双实例数据搬移切换流量。第一步在新目录编译安装新版本。我习惯把不同版本的 Redis 放在不同的目录比如mkdir -p /opt/redis/redis-7.2.5 cd /usr/local/src/redis-7.2.5 make -j$(nproc) make install PREFIX/opt/redis/redis-7.2.5这样/opt/redis/redis-7.2.5/bin/下会有redis-server、redis-cli等二进制文件不会污染原来的环境。第二步准备新实例的配置文件和端口。这里有个关键点我建议新实例先监听一个临时端口比如 6390同时开启 AOF 和 RDB 持久化数据目录设置到独立位置避免和旧实例共用。port 6390 daemonize yes dir /opt/redis/data/redis-7.2.5 appendonly yes dbfilename dump-7.2.5.rdb第三步把旧实例的数据导入新实例。最简单的做法是用redis-cli --rdb或者用MIGRATE命令迁移但在大版本跨度的场景下我强烈推荐用--pipe模式或者写脚本导出导入。这里以redis-cli直接导 RDB 文件的方式为例如果你用的是新版 Redis 直接读取旧版 RDB 文件可以先把旧实例的dump.rdb复制到新实例的数据目录里然后启动新实例看日志。如果新版实例报错说明 RDB 文件不兼容那就要走在线迁移的方式。最稳妥的在线迁移是用主从复制把新实例作为旧实例的从库连接等待同步完成然后做主从切换。步骤如下redis-cli -p 6390 SLAVEOF 127.0.0.1 6379然后观察同步状态redis-cli -p 6390 INFO replication当master_link_status为up且master_repl_offset和旧实例的 offset 一致时说明数据已经追平。然后手动把新实例提升为主库redis-cli -p 6390 SLAVEOF NO ONE第四步做业务切换。这里的关键是不要在切换的一瞬间直接断掉旧实例。建议先用临时端口验证新实例的读写待业务方确认无异常后再改负载均衡或客户端配置把流量指向新端口。旧实例保留观察一段时间等确认稳定后再关闭。第五步数据校验。除了DBSIZE之外我一般还会抽查几个关键业务 key 的值同时检查过期 key 的 TTL 情况。因为 Redis 版本升级后过期 key 的淘汰策略可能有细微变化如果某些 key 的剩余过期时间异常需要逐个排查。3. 实操过程全记录一次完整的 Redis 6.2 → 7.2 升级这一节我直接演示一次完整的实操模拟一个典型的 Linux 服务器环境CentOS 7.9原有 Redis 6.2.8准备升级到 Redis 7.2.5。3.1 环境检查和初始数据备份先连接服务器跑一遍检查命令cat /etc/redhat-release # CentOS Linux release 7.9.2009 (Core) gcc --version # gcc (GCC) 4.8.5看到这个 gcc 版本就知道必须先把工具链升级否则 Redis 7.2.5 编译必然报错。CentOS 7 上通过 yum 默认装不到高版本 gcc有两种处理思路一种是使用devtoolset另一种是使用scl配合rh-gcc。我用的是 devtoolset 方式yum install -y centos-release-scl yum install -y devtoolset-11 scl enable devtoolset-11 bash注意scl enable只在当前 shell 会话生效如果你后续的编译命令在新的终端里执行需要重新启用或者可以直接用绝对路径source /opt/rh/devtoolset-11/enable启用后再确认一下gcc --version # gcc (GCC) 11.2.1接下来备份原有 Redis 数据redis-cli -h 127.0.0.1 -p 6379 -a your_password BGSAVE sleep 2 redis-cli -h 127.0.0.1 -p 6379 -a your_password INFO persistence确认rdb_bgsave_in_progress:0之后拷贝备份文件mkdir -p /data/backup/redis_6828 cp /var/lib/redis/dump.rdb /data/backup/redis_6828/dump_$(date %F).rdb cp /etc/redis/redis.conf /data/backup/redis_6828/redis.conf.bak redis-cli -h 127.0.0.1 -p 6379 -a your_password CONFIG GET save redis-cli -h 127.0.0.1 -p 6379 -a your_password CONFIG GET appendonly到这里环境检查和备份就绪。3.2 编译安装新版本并启动验证下载 Redis 7.2.5 源码cd /usr/local/src wget https://download.redis.io/releases/redis-7.2.5.tar.gz tar -zxvf redis-7.2.5.tar.gz cd redis-7.2.5注意刚才的scl enable devtoolset-11 bash生效的终端编译前再跑一遍gcc --version确认。如果不针对当前 shell 生效编译时会报错。执行编译make -j$(nproc) MALLOClibc这里我特意加了MALLOClibc意思是使用系统自带的libc内存分配器而不是默认的jemalloc。为什么因为有些 CentOS 服务器上编译 jemalloc 时会报Unknown test function或者链接阶段出现undefined reference。用libc能绕开这类坑虽然性能上 jemalloc 通常更好但对于很多业务场景libc 的分配策略已经够用。如果你坚持要用默认的 jemalloc需要保证系统有足够的编译工具和依赖库。编译完成后先安装到独立目录make install PREFIX/opt/redis/redis-7.2.5在替换正常服务之前写一个临时测试配置文件cat /tmp/redis-test-725.conf EOF port 6390 daemonize yes dir /tmp/redis-test-data dbfilename dump-test.rdb appendonly no EOF mkdir -p /tmp/redis-test-data /opt/redis/redis-7.2.5/bin/redis-server /tmp/redis-test-725.conf然后验证/opt/redis/redis-7.2.5/bin/redis-cli -p 6390 ping # PONG /opt/redis/redis-7.2.5/bin/redis-cli -p 6390 info server | grep redis_ver # redis_version:7.2.5确认 7.2.5 能正常启动后关闭测试实例/opt/redis/redis-7.2.5/bin/redis-cli -p 6390 shutdown3.3 数据迁移和主从同步切换新实例正式启动前先把旧数据导入。我的做法是先启动新实例并开启主从同步。写一个正式的新实例配置cat /opt/redis/redis-7.2.5/redis-725.conf EOF port 6390 daemonize yes dir /opt/redis/data/redis-725 dbfilename dump.rdb appendonly yes appendfilename appendonly.aof logfile /opt/redis/logs/redis-725.log requirepass your_new_password EOF mkdir -p /opt/redis/data/redis-725 mkdir -p /opt/redis/logs /opt/redis/redis-7.2.5/bin/redis-server /opt/redis/redis-7.2.5/redis-725.conf然后让新实例成为旧实例的从库/opt/redis/redis-7.2.5/bin/redis-cli -p 6390 -a your_new_password SLAVEOF 127.0.0.1 6379注意旧实例如果设了密码新实例作为从库时需要配置masterauth。在我的例子里旧实例密码是your_password所以要在新实例配置里加上masterauth your_password修改配置后重启新实例再重新发起SLAVEOF。查看同步状态/opt/redis/redis-7.2.5/bin/redis-cli -p 6390 -a your_new_password INFO replication重点看master_link_status:up和slave_repl_offset是否持续增长并最终和主库一致。这里有一个细节如果旧实例开启了 AOF并且写入量很大同步过程可能会持续较长时间。期间不要中断也不要重复执行 SLAVEOF。等追平后把新实例提升为主/opt/redis/redis-7.2.5/bin/redis-cli -p 6390 -a your_new_password SLAVEOF NO ONE然后对比数据量redis-cli -p 6379 -a your_password DBSIZE /opt/redis/redis-7.2.5/bin/redis-cli -p 6390 -a your_new_password DBSIZE理论上两边 key 数量完全一致。但注意DBSIZE 是近似值在同步追平后会更精确所以最好等到同步暂停、写入平稳后再比较。3.4 切换到新实例并收尾确认数据一致后就可以做流量的切换。我在生产环境中的切换策略是先切一小部分只读流量验证稳定后再切全量。如果你们用的是自建的客户端配置直接改端口号如果用了 HAProxy 或 Nginx 做代理就改 upstream 地址。切换期间要持续观察新实例的 QPS、连接数、内存使用率是否出现大量LOADING或SYNC日志客户端是否有重连或报错稳定运行至少 24 小时后再关闭旧实例redis-cli -p 6379 -a your_password SHUTDOWN NOSAVE这里的NOSAVE是刻意的因为数据已经完整迁移到新实例旧实例再保存一次 RDB 反而会增加无谓的磁盘写入而且如果旧实例停止过程中有新写入这个 RDB 也未必是最新状态没必要保留。最后把新实例的配置里加上开机自启动。CentOS 7 上我习惯用 systemd 管理写一个 unit 文件cat /etc/systemd/system/redis-725.service EOF [Unit] DescriptionRedis 7.2.5 Server Afternetwork.target [Service] ExecStart/opt/redis/redis-7.2.5/bin/redis-server /opt/redis/redis-7.2.5/redis-725.conf PIDFile/var/run/redis-725.pid Restartalways Userredis Groupredis [Install] WantedBymulti-user.target EOF systemctl daemon-reload systemctl enable redis-725 systemctl start redis-725注意User 要改成你实际运行 Redis 的用户如果还没单独建 redis 用户先建一个useradd -r -s /sbin/nologin redis chown -R redis:redis /opt/redis/data/redis-725 /opt/redis/logs /opt/redis/redis-7.2.5到这里整个升级过程就算完整跑完了。4. 升级后的验证与常见问题排查升级完成后不是说你看到redis-server在跑就算成功了。我习惯做一套系统性的验证把潜在隐患提前暴露出来。4.1 升级后的必做验证项验证项可以分为数据层、功能层、性能层三层。数据层验证核对 key 数量、抽查核心业务 key 的类型和 value、比较 TTL。这里有一个容易被忽视的细节不同版本对TTL的返回精度可能有变化7.x 版本对过期时间的精度控制更精细如果你的业务依赖TTL做缓存续期要重新确认逻辑不受影响。功能层验证重点测试 ACL 权限、订阅发布、Lua 脚本、管道命令这些在旧版本上跑过的功能。7.2 开始Lua脚本的默认行为有调整比如redis.call在脚本中的错误处理更严格了之前能跑的脚本可能在新版本上直接报错。所以升级后必须把业务侧用到 Lua 的脚本完整回归一遍。性能层验证生产环境建议用redis-benchmark或者你们自有的压测工具打一轮基础性能数据。重点关注延迟分布、P99 延迟、吞吐量。升级到 7.x 之后默认的多线程 IO 参数需要手动调整才能生效所以要在压测前先确认配置。4.2 常见问题速查表我把升级过程中最常遇到的问题整理成一个速查表方便大家直接对照现象可能原因解决办法编译时报gcc: command not found没安装 gccyum install -y gccCentOS 上注意先启用 devtoolset编译时报unknown type name adstest functionsgcc 版本过旧升级 gcc 到 9 或使用 devtoolset-11启动时报Bad directive or wrong number of arguments配置文件中包含旧版本废弃的指令检查日志定位具体配置行注释或删除后重启新版启动后连不上redis-cli ping没响应protected-mode默认开启或 bind 配置变更检查bind、protected-mode、requirepass配置主从同步一直处于down状态masterauth未配置或密码不正确在新实例配置中添加masterauth并重启升级后INFO memory显示的used_memory波动较大从 jemalloc 切换到 libc 或反之这是正常现象不同分配器的内存统计口径不同观察峰值即可业务客户端连接报错Redis error: NOAUTH新实例设了密码但客户端配置未更新更新客户端连接密码Lua 脚本报错ERR Error running script7.x 对 Lua 错误处理更严格检查脚本逻辑捕获并处理redis.call异常升级后 QPS 明显下降IO 多线程未开启或分配器不同检查io-threads、io-threads-do-reads配置以上这些坑我基本都踩过一遍。特别是 gcc 版本和masterauth这两个问题操作频率最高。很多人编译不过去就反复重装依赖或者重启实例后一直卡在SLAVEOF同步不过去最后发现就是密码没配。这里提醒大家升级之前先把新实例CONFIG GET requirepass和旧实例的masterauth全部对齐就不会有这种低级问题。4.3 一个很多人忽略的问题CONFIG REWRITE 和配置文件一致性升级完成之后你可能会顺手敲一句redis-cli CONFIG REWRITE这行命令的作用是把当前运行时内存中的配置写回配置文件。但要注意如果你用的是旧版本的配置文件直接启动新版本且新版本里有些配置项语义变了CONFIG REWRITE会把旧结构固化成新结构导致以后想回滚到旧版本的时候旧的配置文件已经被覆盖了。所以我建议升级前保留一份干净的旧配置备份升级后不要急于执行CONFIG REWRITE先用几天观察确认稳定后再把运行时配置固化。4.4 回滚预案升级失败后怎么快速恢复任何人都可能遇到升级后业务不兼容、数据访问异常的情况。回滚预案必须提前写好而不是出问题了再想。回滚的前提是你保留了旧版本二进制、旧配置文件、以及完整的数据备份。回滚步骤停掉新实例/opt/redis/redis-7.2.5/bin/redis-cli -p 6390 -a your_new_password SHUTDOWN把旧实例恢复启动。如果你旧实例还在跑但只是切换了流量那直接改回端口映射或客户端配置即可如果旧实例已经关了用备份的配置启动/usr/local/bin/redis-server /etc/redis/redis.conf验证旧实例的数据是否还在。如果发现数据不完整因为你切流量后旧实例没有再写入新数据需要用备份的 RDB 文件恢复数据。恢复方法把备份的 dump.rdb 放到 Redis 数据目录覆盖现有文件再启动服务。确认回滚成功后暂时不要立刻重新尝试升级先把问题定位清楚再规划下次升级窗口。这里有个核心原则升级前保证数据可回滚比升级本身更重要。只要数据在版本折腾坏了大不了重新装数据丢了那就是事故。5. 结合业务场景看升级后的配置优化很多人升级到新版本就觉得完事了其实后面还有一道工序根据新版本的能力重新审视旧配置把该用的新特性用起来。以 Redis 7.x 为例我会重点看这几个方向ACL 权限管控。旧版本如果只靠requirepass做全量密码升级到 7.x 后建议逐步迁移到 ACL。ACL 可以做到按用户分配权限比如让业务账号只能访问指定 key 前缀运维账号有全部权限。这个能力在多人协作的团队里特别实用能减少误操作带来的风险。用法举例acl setuser biz_user on biz_password ~app:* read write string hash list set zsetIO 多线程。Redis 6.0 开始支持 IO 多线程默认关闭。7.x 继续沿用这个模型。如果你的机器是多核 CPU而且访问量大开启后能明显提升吞吐。配置方式io-threads 4 io-threads-do-reads yes注意两点io-threads-do-reads在 6.x 里是实验特性7.x 相对稳定线程数建议不要超过 CPU 核心数减一开启后要做压测观察延迟是否明显改善不要盲目开。Redis Functions。7.0 引入了 Redis Functions用来替代一部分 Lua 脚本的场景。它的好处是脚本是持久化存储的不依赖客户端每次上传且支持权限控制。如果你业务里大量使用 Lua 做原子操作建议评估迁移到 Functions。内存碎片整理。7.x 对activedefrag有改进默认仍是关闭。如果之前你遇到过used_memory远大于used_memory_rss的情况可以打开碎片整理activedefrag yes active-defrag-threshold-lower 10 active-defrag-threshold-upper 100 active-defrag-ignore-bytes 100mb开启后观察 CPU 和延迟如果碎片整理正常且性能影响可接受就保持开启。持久化策略的再平衡。新版本对 AOF 的appendfsync策略、RDB 的save参数都有细微调整。升级后建议重新审视如果你的业务对数据丢失容忍度低考虑 AOF 为主同时开启aof-use-rdb-preamble yes7.x 默认开启这样重放 AOF 时会先加载 RDB 再增量恢复速度更快。6. 写在最后的实操体会我做了那么多次 Redis 升级最大的感受是升级本身的难度往往不在命令执行上而在于前期的评估和回滚预案是否到位。Linux 环境千差万别依赖链、编译环境、安全策略都不同同一套步骤换个机器跑可能就出幺蛾子。所以我在每次升级前都会把服务器信息、版本信息、数据大小、备份状态全部打印出来存档哪怕不出问题记录的这些信息以后排查线上问题时也很有用。另外有一个小技巧分享给你们升级完成后的前几天我习惯每天扫一次redis.log重点关注WARNING级别的输出。7.x 版本会有类似WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128的提示这种虽然不影响启动但意味着你的内核参数需要调整否则高并发下连接数受限制。遇到这种提示直接按提示修改/etc/sysctl.conf中的somaxconn和tcp_max_syn_backlog然后sysctl -p生效即可。最后再提醒一句别以为升到最新版本就万事大吉。Redis 7.2 虽然功能丰富但社区的反馈里也出现过一些边缘场景下的 bug比如某些平台下的 zombie process 清理、fork 阻塞导致延迟波动。所以固定一个经过充分验证的稳定版本比追新版本更重要。升级的频率控制在一年一次左右除非新版本有明确的安全补丁或你需要的特性否则不轻易动生产环境。希望这份实操记录对你有帮助如果你的环境和我的不同也欢迎在评论区提出具体问题我尽量给出定位思路。
