前言
前阵子redis报出存在hyperloglog 远程代码执行漏洞，具体表现是“经过身份验证的本地用户可以使用特制的字符串来触发 hyperloglog 操作中的堆栈/堆越界写入，从而可能导致远程代码执行”。所以生产环境的redis需要及时进行版本升级，笔者的redis应用属于6.x系列，所以也需要将redis升级到6.2.19，这个版本也是当前redis的最新版本。为了保障redis服务稳定，升级过程中必须不能停机，本篇文章用于记录不停机升级redis的过程，希望对各位读者有所帮助。
一、说在前面
（一）受影响的redis版本如下：
- 8.0.* <= Redis < 8.0.3
- 7.4.* <= Redis < 7.4.5
- 7.2.* <= Redis < 7.2.10
- 2.8 <= Redis < 6.2.19
（二）redis服务升级要求
redis为cluster模式且存在多个节点，应用的当前版本为6.2.x需要升级到6.2.19版本，升级过程中不能暂停redis服务
二、升级redis
（一）下载redis应用
下载redis应用可以有2种方式，去官网或者去github上面下载二进制的安装包
- 官网：
https://redis.io/downloads/ - github：
https://github.com/redis/redis/releases
官网的下载页面感觉有点花里胡哨，个人比较推荐直接去github上面下载
image.png
（二）redis服务摸底（重要！！）
如果redis服务不是你搭建的，那么升级之前对redis集群做一下摸底工作还是很有必要的，避免升级过程中遗漏了某些环节或者节点，导致升级过程中出现其他不必要的问题。
1. 使用INFO SERVER查看当前的redis应用信息
INFO SERVER命令会输出当前连接redis服务端的信息，我们可以从redis_version查看当前redis节点的版本，从redis_mode查看redis节点的模式以及其他redis节点的运行和编译信息。
image.png
2. 使用CLUSTER NODES查看redis集群信息
为了不遗漏任何一个redis集群节点的升级，我们需要知道当前所有redis节点，以及对应的主从关系，了解当前的主从关系信息会直接对我们升级的顺序有直接的影响。
cluster nodes命令的输出结果比较多，简单概括的话格式为：D-地址-角色-父ID-Ping-Pong-Epoch-状态-槽，我们需要留意的主要是地址、角色和父ID这三列。从图中我们可以看到，目前一共有3主3从共6个节点，我们这里用端口号简单做一下标识
- master1：7001 slave1：7007
- master2：7006 slave2：7003
- master3：7002 slave3：7005
iCLUSTER NODES执行结果
3. 使用INFO REPLICATION巡检节点的延迟情况
使用redis-cli客户端切换到从节点上，观察从节点和主节点之前是否存在延迟，若master_repl_offset-slave_read_repl_offset的差值为0则说明当前从节点和主节点的数据是没有延迟的，基本一致的。只要这个差值处于正常区间即可，如果差值很大那么在升级之前最好先解决掉主从节点的延迟问题。
INFO REPLICATION命令执行结果
（三）编译redis
注意，我们并不是从0到1的搭建redis服务，而是做redis的升级，因此在编译redis的时候记得要指定好redis编译结果的路径，避免直接覆盖掉正常运行的redis服务，导致不可控的问题发生。
编译redis其实并不复杂，解压redis的安装包后，cd进入对应的目录后按照下面的方法进行编译就行，这里需要注意的是install的时候需要指定好redis的编译结果输出到哪个目录，像我这里的话就是输出到当前安装包的target目录下面。
tar -xzvf redis-6.2.19.tar.gz
cd redis-6.2.19
make -j 8
# 先手动将需要的文件输出到指定的目录
make PREFIX=/opt/sourceFile/redis-6.2.19/target install
（四）新旧redis应用替换
我们需要先备份原有redis应用后，再进行新版本redis应用的替换，假设我们的现有的redis是部署在/usr/local/redis目录下面，我们可以将对应的bin目录直接备份，然后把上一步打包出来的bin目录替换上去。如果原先的redis服务有做过用户授权，那么这里还需要注意是否需要做额外的授权。
PS：这里需要解释一下，直接改bin目录不会影响正常运行的redis服务，因为Linux运行redis的时候就已经把应用加载在内存中了。
cd /usr/local/redis
mv bin bin.20250911.bak
cp -r /opt/sourceFile/redis-6.2.19/target/bin ./
# 可选,若是应用账号启动,则需要手动授权
chown user:user bin
（五）节点切换
整个redis不停机升级过程中，最耗时的就是节点切换了，我们需要先将所有的从节点依次进行升级，然后再将主节点切换成从节点，再进行新的从节点升级。不停机升级本质上就是让主节点一直保持可用的状态
1. 从节点升级
使用redis-cli登录从节点，执行shutdown save将从节点的缓存落库。
#redis-cli 登录从节点应用后，执行shutdown命令
shutdown save
关停从节点后，再自行重启从节点，然后重新使用下面三条命令依次检查服务是否升级成功，当前的集群状态以及偏移量是否正常。
INFO SERVER
CLUSTER NODES
INFO REPLICATION
2. 主节点升级
使用redis-cli登录主节点，执行CLUSTER FAILOVER命令进行主从切换，命令执行完成后使用CLUSTER NODES命令检查是否切换成功。
CLUSTER FAILOVER
主节点降为从节点后，接下来的操作就和从节点升级一样，shutdown save后再重启就行。
等到所有主节点依次切换从节点后完成升级，理论上来说此时就正式完成所有节点的升级工作了，如果有需要还原原先的主从关系，则可以通过CLUSTER FAILOVER来将节点还原为以前的角色。
PS：由于升级过程中涉及主从节点的切换，建议在切换过程中，操作人员自行记录一下已升级的节点，避免遗漏。
网友评论