Redis版本升级3.0.7~4.0.6

redis版本升级3.0.7~4.0.6

今天在线上操作了一个Redis的版本升级，在整个操作的过程中，遇到了一些问题，这里记录下来。

本次Redis升级的过程中，我们的目标版本是4.0.6，正常情况下，推荐的做法是大版本之间的连续升级，也就是：

3.0.7 ~ 3.2.x ~ 4.0.6

实际过程中，跳过了中间的3.2.x版本，直接从3.0.7版本升级到4.0.6版本。

升级方案

1、Redis主从架构如下，一主两从

2、先将从库升级成高版本的4.0.6，注意，升级过程中，使用原来低版本的配置文件，保证参数一致，只是更新一下启动的Redis软件版本即可。

3、业务确认访问无误后，对上述架构进行切换操作

4、业务验证主库访问无误后，重新搭建高版本4.0.6的新从库即可

在实际的操作过程中，当我们将从库切换成4.0.6之后，业务访问出现了下面的问题：

报错信息写的很全面，也给出了基本的解决方案，就是设置这个参数protected-mode为no即可，我们按照这个提示进行调整，如下：

redis-cli  -p 22140
127.0.0.1:22140> config get protect*
1) "protected-mode"
2) "yes"
127.0.0.1:22140> config set protected-mode no
OK
127.0.0.1:22140> config rewrite
OK

确实，调整完了之后，报错就消失了。

现在我们来看这个protected-mode参数的意思：

Redis中的protected-mode是为了增加Redis的安全而设置的参数，从Redis3.2版本开始添加，而我们恰好跳过了这个版本，这个参数生效有2个前提，分别是：

1、Redis本身没有设置bind ip

2、Redis本身没有设置密码

一旦这个参数设置成了yes，启用后，所有的client只能从环回地址127.0.0.1访问Redis。

看了上面的介绍，那么可以得出结论，解决这个问题就有3个办法：

1、Redis设置bind IP

2、Redis本身设置密码

3、将这个参数关闭，命令关闭、再持久化到配置文件即可

最终，我们采用了方案3来执行

总结：

Redis版本升级过程中，不同的版本在参数方面可能会有不同，在升级之前，需要充分测试，否则直接升级容易造成不可预知的后果;

本次迁移过程中，在从库校验阶段出现问题，属于计划内发现问题，相对影响较小，如果直接升级主库，则会造成服务不可用。

因此，参数的可用性、兼容性、一致性校验是版本升级中不可缺失的一环。