今天在线上操作了一个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版本升级过程中，不同的版本在参数方面可能会有不同，在升级之前，需要充分测试，否则直接升级容易造成不可预知的后果;
本次迁移过程中，在从库校验阶段出现问题，属于计划内发现问题，相对影响较小，如果直接升级主库，则会造成服务不可用。
因此，参数的可用性、兼容性、一致性校验是版本升级中不可缺失的一环。
