一、迁移背景
漏洞说明 ：现有Redis 6.0.10存在 Redis LUA UAF 远程代码执行漏洞(CVE‑2025‑49844)，需要升级到7.x版本进行漏洞修复。
本次目标版本：Redis‑7.4.6 生产环境旧Redis存有业务数据，要求迁移数据完成后，业务项目无需重启，实现平滑版本升级。
⚠️**重要前提**：本次采用主从复制迁移方案；操作前务必确认旧实例为Master主库。
二、环境说明
| 实例 | 版本 | 端口 | 角色 |
|---|---|---|---|
| 旧Redis | 6.0.10 | 6379 | Master（业务正在使用） |
| 新Redis | 7.4.6 | 6380（临时） | Replica从库 |
三、操作步骤
3.1 确认旧Redis角色（确认是Master主库）
连接旧Redis客户端
redis-cli -p 6379输入认证密码，再查看复制信息
127.0.0.1:6379> auth 你的密码
OK
127.0.0.1:6379> info replication重点看输出：
# Replication
role:master # <font color="red">这里必须是master，才可以继续往下操作</font>
connected_slaves:0
......如果
role是slave，说明当前是从库，不能直接作为数据源，需要先切换主从再迁移。
3.2 配置新版本Redis为从库（临时端口6380）
修改新版本redis.conf配置文件
-
修改监听端口，不能和旧主库端口冲突
port 6380
-
增加主从同步配置，指向旧的6379主库，填写主库访问密码
replicaof 127.0.0.1 6379
masterauth "你的密码"
⚠️**注意：先启动7.4.6的Redis实例，此时新实例作为从库开始全量同步旧库数据** 启动新版本redis：
redis-server ../etc/redis.conf3.3 校验主从数据同步是否完整
校验思路：对比主库、从库各个db的key数量，数量完全一致代表同步完成
旧主库（6379）查看key统计
redis-cli -p 6379
127.0.0.1:6379> auth 你的密码
OK
127.0.0.1:6379> INFO keyspace示例输出：
# Keyspace
db0:keys=86,expires=0,avg_ttl=0,subexpiry=0
db6:keys=14,expires=0,avg_ttl=0,subexpiry=0新从库（6380）查看key统计
redis-cli -p 6380
127.0.0.1:6380> auth 你的密码
OK
127.0.0.1:6380> INFO keyspace示例输出：
# Keyspace
db0:keys=86,expires=0,avg_ttl=0,subexpiry=0
db6:keys=14,expires=0,avg_ttl=0,subexpiry=0✅判断标准：所有db下keys数量、过期key数量完全相等，代表数据同步完成；如果不一致，等待同步，禁止进行切换操作！
数据量大场景，全量同步需要时间，不要立刻切换。
四、业务切换（低峰期操作！）
⚠️**强烈建议选择业务访问量少的时间段执行切换，减少业务抖动风险**
4.1 修改新版本Redis配置，取消从库身份，切回业务端口6379
编辑7.4.6的redis.conf
-
修改端口为业务原端口
port 6379
-
注释/删除主从复制两行配置
#replicaof 127.0.0.1 6379
#masterauth "你的密码"
4.2 停止旧版本Redis 6.0.10
#查找旧redis进程PID
ps -ef|grep redis
#杀死旧redis进程
kill -9 旧redis的PID⚠️确认kill的是旧6.0.10进程，不要误杀新版本7.4.6进程！等旧的redis进程停止后，在停止掉7.4.6，保证在停止6.0.10的时候，已经同步数据到7.4.6
4.3 启动新版本Redis7.4.6（端口6379对外提供服务）
进入新版本bin目录执行：
redis-server ../etc/redis.conf4.4 验证升级结果
连接6379端口，查看Redis版本
redis-cli -p 6379
127.0.0.1:6379> auth 你的密码
OK
127.0.0.1:6379> INFO server重点查看：
# Server
redis_version:7.4.6 #<font color="red">显示7.4.6，代表版本升级成功</font>
redis_mode:standalone
......再执行INFO keyspace核对key数量，确认数据还在。
✨最后一步：务必进行业务功能测试，验证业务读写Redis正常，才算迁移完整结束。
五、踩坑与注意事项
- 主从同步期间，旧主库不能停机，否则同步失败；
- 密码配置注意：
masterauth密码需要带双引号，防止特殊字符解析异常； - 端口冲突：新版本先使用临时端口，不要直接占用6379；
- 必须等keyspace key计数完全一致再切换，不要凭主观感觉认为同步完成；
- 切换时先停旧redis，再启动新redis占用6379端口；
- 该方案实现业务无需重启，因为业务连接的还是6379端口，只是底层实例换成7.4.6；
- 操作前建议备份旧RDB/AOF数据，作为兜底回滚方案。
六、回滚思路（应急）
如果新版本出现异常：
- 停止7.4.6的6379实例；
- 重新启动旧版本Redis6.0.10监听6379端口，业务直接恢复；
- 排查迁移问题后再重新升级。