印刻数据库

外观

Redis 升级与回滚 ​

Redis 版本升级是运维工作中的重要环节，合理的升级策略可以确保服务的稳定性和安全性。同时，完善的回滚机制可以在升级出现问题时快速恢复服务。本文档将详细介绍 Redis 升级与回滚的完整流程。

升级前准备 ​

1. 版本兼容性检查 ​

1.1 检查当前版本 ​

bash
# 查看当前 Redis 版本
redis-cli --version
redis-cli INFO server | grep redis_version

1.2 查看目标版本 ​

访问 Redis 官方网站（https://redis.io/download）查看目标版本的发布说明和变更日志，重点关注：

  • 新特性
  • 已知问题
  • 兼容性变更
  • 废弃的命令和配置

1.3 检查客户端兼容性 ​

确保应用程序使用的 Redis 客户端库与目标版本兼容。

2. 制定升级计划 ​

2.1 升级方式选择 ​

根据部署架构选择合适的升级方式：

  • 单机模式：直接升级
  • 主从复制：先升级从节点，再升级主节点
  • Redis Sentinel：先升级 Sentinel 节点，再升级从节点，最后升级主节点
  • Redis Cluster：滚动升级，一次升级一个节点

2.2 升级时间窗口 ​

选择业务低峰期进行升级，如凌晨 2-4 点。

2.3 人员安排 ​

确保升级过程中有足够的人员支持，包括：

  • 主要负责人：负责整个升级过程的协调和决策
  • 技术实施人员：负责执行升级操作
  • 监控人员：负责监控升级过程中的系统状态
  • 应用开发人员：负责验证应用程序兼容性

3. 数据备份 ​

3.1 执行全量备份 ​

bash
# 执行 RDB 持久化
redis-cli BGSAVE

# 备份 RDB 文件
cp /path/to/redis/data/dump.rdb /path/to/backup/dump.rdb.$(date +%Y%m%d%H%M%S)

# 如果启用了 AOF，备份 AOF 文件
cp /path/to/redis/data/appendonly.aof /path/to/backup/appendonly.aof.$(date +%Y%m%d%H%M%S)

3.2 验证备份完整性 ​

bash
# 检查备份文件大小
ls -lh /path/to/backup/

# 验证 RDB 文件完整性
redis-check-rdb /path/to/backup/dump.rdb.$(date +%Y%m%d%H%M%S)

# 验证 AOF 文件完整性
redis-check-aof /path/to/backup/appendonly.aof.$(date +%Y%m%d%H%M%S)

4. 环境准备 ​

4.1 下载目标版本 ​

bash
# 下载 Redis 目标版本
wget https://download.redis.io/releases/redis-7.2.6.tar.gz

tar xzf redis-7.2.6.tar.gz
cd redis-7.2.6

4.2 编译目标版本 ​

bash
# 编译 Redis
make

# 安装 Redis（可选，建议安装到不同目录）
sudo make install PREFIX=/usr/local/redis-7.2.6

4.3 准备配置文件 ​

bash
# 复制当前配置文件
cp /etc/redis/redis.conf /etc/redis/redis.conf.bak

# 根据目标版本更新配置文件
# 检查并修改废弃的配置项
# 调整新添加的配置项

5. 测试环境验证 ​

在测试环境中模拟升级过程，验证：

  • 升级过程是否顺利
  • 应用程序是否兼容
  • 性能是否正常
  • 数据是否完整

升级步骤 ​

1. 单机模式升级 ​

1.1 停止当前 Redis 实例 ​

bash
# 停止 Redis 服务
systemctl stop redis

# 或使用 redis-cli 停止
redis-cli SHUTDOWN

1.2 替换 Redis 二进制文件 ​

bash
# 备份当前二进制文件
mv /usr/bin/redis-server /usr/bin/redis-server.bak
mv /usr/bin/redis-cli /usr/bin/redis-cli.bak

# 复制新的二进制文件
cp /usr/local/redis-7.2.6/bin/redis-server /usr/bin/
cp /usr/local/redis-7.2.6/bin/redis-cli /usr/bin/

1.3 更新配置文件 ​

bash
# 根据目标版本更新配置文件
vi /etc/redis/redis.conf

1.4 启动新的 Redis 实例 ​

bash
# 启动 Redis 服务
systemctl start redis

# 或使用命令行启动
redis-server /etc/redis/redis.conf

1.5 验证升级结果 ​

bash
# 检查 Redis 版本
redis-cli --version
redis-cli INFO server | grep redis_version

# 验证数据完整性
redis-cli DBSIZE
redis-cli GET <test-key>

# 验证应用程序连接
# 执行应用程序的健康检查

2. 主从复制升级 ​

2.1 升级从节点 ​

  1. 停止从节点：

    bash
    redis-cli -h <slave-host> -p <slave-port> SHUTDOWN

  2. 替换二进制文件：

    bash
    # 替换从节点的二进制文件
# 同单机模式

  3. 更新配置文件：

    bash
    # 更新从节点的配置文件
# 同单机模式

  4. 启动从节点：

    bash
    redis-server /etc/redis/redis.conf

  5. 验证从节点状态：

    bash
    redis-cli -h <slave-host> -p <slave-port> INFO replication

2.2 升级主节点 ​

  1. 执行手动故障转移（可选，适用于主从切换）：

    bash
    # 在从节点上执行手动故障转移
redis-cli -h <slave-host> -p <slave-port> REPLICAOF NO ONE

# 更新其他从节点指向新的主节点
redis-cli -h <other-slave-host> -p <other-slave-port> REPLICAOF <new-master-host> <new-master-port>

  2. 停止原主节点：

    bash
    redis-cli -h <old-master-host> -p <old-master-port> SHUTDOWN

  3. 替换二进制文件：

    bash
    # 替换原主节点的二进制文件
# 同单机模式

  4. 更新配置文件：

    bash
    # 更新原主节点的配置文件
# 同单机模式

  5. 启动原主节点作为从节点：

    bash
    redis-server /etc/redis/redis.conf
redis-cli -h <old-master-host> -p <old-master-port> REPLICAOF <new-master-host> <new-master-port>

  6. 验证主从关系：

    bash
    redis-cli -h <new-master-host> -p <new-master-port> INFO replication

3. Redis Sentinel 升级 ​

3.1 升级 Sentinel 节点 ​

  1. 停止 Sentinel 节点：

    bash
    redis-cli -h <sentinel-host> -p <sentinel-port> SHUTDOWN

  2. 替换 Sentinel 二进制文件：

    bash
    # 备份当前 Sentinel 二进制文件
mv /usr/bin/redis-sentinel /usr/bin/redis-sentinel.bak

# 复制新的 Sentinel 二进制文件
cp /usr/local/redis-7.2.6/bin/redis-sentinel /usr/bin/

  3. 更新 Sentinel 配置文件：

    bash
    vi /etc/redis/sentinel.conf

  4. 启动 Sentinel 节点：

    bash
    redis-sentinel /etc/redis/sentinel.conf

  5. 验证 Sentinel 状态：

    bash
    redis-cli -h <sentinel-host> -p <sentinel-port> INFO sentinel

3.2 升级 Redis 节点 ​

按照主从复制的升级步骤，先升级从节点，再升级主节点。

4. Redis Cluster 升级 ​

4.1 滚动升级 ​

Redis Cluster 支持滚动升级，一次升级一个节点，不会影响整个集群的可用性。

  1. 选择要升级的节点：

    bash
    # 查看集群节点
redis-cli CLUSTER NODES

  2. 将节点设置为从节点（如果是主节点）：

    bash
    # 在主节点上执行手动故障转移
redis-cli -h <master-host> -p <master-port> CLUSTER FAILOVER

  3. 停止节点：

    bash
    redis-cli -h <node-host> -p <node-port> SHUTDOWN

  4. 替换二进制文件：

    bash
    # 替换节点的二进制文件
# 同单机模式

  5. 更新配置文件：

    bash
    # 更新节点的配置文件
# 同单机模式

  6. 启动节点：

    bash
    redis-server /etc/redis/redis.conf

  7. 验证节点状态：

    bash
    redis-cli -h <node-host> -p <node-port> CLUSTER INFO
redis-cli -h <node-host> -p <node-port> CLUSTER NODES

  8. 重复上述步骤，直到所有节点升级完成。

升级后验证 ​

1. 基本功能验证 ​

bash
# 检查 Redis 版本
redis-cli INFO server | grep redis_version

# 验证数据完整性
redis-cli DBSIZE
redis-cli GET <test-key>
redis-cli MGET <key1> <key2> <key3>

# 验证命令执行
redis-cli SET test-key test-value
redis-cli GET test-key

2. 性能验证 ​

bash
# 使用 redis-benchmark 进行性能测试
redis-benchmark -h <host> -p <port> -t set,get,incr -n 100000 -q

# 比较升级前后的性能指标

3. 应用程序验证 ​

  • 执行应用程序的健康检查
  • 验证应用程序的核心功能
  • 监控应用程序的响应时间
  • 检查应用程序日志，确保没有连接错误

4. 监控系统验证 ​

  • 检查监控系统中的 Redis 指标
  • 验证内存使用率、CPU 使用率、连接数等指标
  • 确保没有异常告警

回滚策略 ​

1. 回滚触发条件 ​

当出现以下情况时，应执行回滚操作：

  • 升级后出现严重的性能问题
  • 应用程序无法正常连接 Redis
  • 数据丢失或损坏
  • 出现大量错误日志
  • 无法解决的兼容性问题

2. 回滚准备 ​

2.1 备份当前状态 ​

在升级前已经执行了全量备份，确保备份文件可用。

2.2 准备回滚脚本 ​

根据部署架构准备回滚脚本，确保回滚过程快速、准确。

3. 回滚步骤 ​

3.1 单机模式回滚 ​

  1. 停止当前 Redis 实例：

    bash
    redis-cli SHUTDOWN

  2. 恢复旧的二进制文件：

    bash
    mv /usr/bin/redis-server /usr/bin/redis-server.new
mv /usr/bin/redis-cli /usr/bin/redis-cli.new
mv /usr/bin/redis-server.bak /usr/bin/redis-server
mv /usr/bin/redis-cli.bak /usr/bin/redis-cli

  3. 恢复旧的配置文件：

    bash
    cp /etc/redis/redis.conf.bak /etc/redis/redis.conf

  4. 恢复数据：

    bash
    cp /path/to/backup/dump.rdb /path/to/redis/data/

  5. 启动 Redis 实例：

    bash
    redis-server /etc/redis/redis.conf

  6. 验证回滚结果：

    bash
    redis-cli INFO server | grep redis_version
redis-cli DBSIZE

3.2 主从复制回滚 ​

  1. 回滚从节点：

    • 停止从节点
    • 恢复旧的二进制文件和配置文件
    • 启动从节点

  2. 回滚主节点：

    • 执行手动故障转移，将一个从节点提升为主节点
    • 停止原主节点
    • 恢复旧的二进制文件和配置文件
    • 启动原主节点作为从节点

3.3 Redis Cluster 回滚 ​

  1. 逐个回滚节点：

    • 停止节点
    • 恢复旧的二进制文件和配置文件
    • 启动节点

  2. 验证集群状态：

    bash
    redis-cli CLUSTER INFO
redis-cli CLUSTER NODES

4. 回滚后验证 ​

  • 验证 Redis 版本是否恢复到升级前的版本
  • 验证数据完整性
  • 验证应用程序连接
  • 验证监控指标

升级最佳实践 ​

1. 版本选择 ​

  • 稳定版本：选择经过充分测试的稳定版本，如 Redis 6.2.x、7.0.x、7.2.x
  • 长期支持版本：优先选择 Redis 官方提供长期支持的版本
  • 跳过有问题的版本：避免使用有已知严重 bug 的版本

2. 升级策略 ​

  • 滚动升级：对于高可用架构，采用滚动升级方式，避免服务中断
  • 先从后主：对于主从架构，先升级从节点，再升级主节点
  • Sentinel 优先：对于 Sentinel 架构，先升级 Sentinel 节点

3. 备份策略 ​

  • 全量备份：升级前必须执行全量备份
  • 备份验证：验证备份文件的完整性
  • 多副本备份：将备份文件存储在多个位置

4. 监控与告警 ​

  • 升级过程监控：实时监控升级过程中的系统状态
  • 设置告警阈值：针对关键指标设置告警阈值
  • 安排专人监控：升级过程中安排专人负责监控

5. 文档记录 ​

  • 记录升级过程：详细记录升级的每一步操作
  • 记录配置变更：记录所有配置文件的变更
  • 记录验证结果：记录升级后的验证结果
  • 记录回滚过程：如果执行了回滚，记录回滚的原因和过程

6. 人员培训 ​

  • 培训升级流程：确保参与升级的人员熟悉升级流程
  • 培训回滚流程：确保参与升级的人员熟悉回滚流程
  • 明确职责分工：明确每个人的职责和分工

常见问题与解决方案 ​

Q1: 升级后出现 "ERR unknown command" 错误 ​

原因：目标版本中废弃了某些命令。

解决方案：

  1. 查看 Redis 日志，确定具体的废弃命令
  2. 更新应用程序，替换废弃的命令
  3. 如果无法立即更新应用程序，可以考虑：
    • 回滚到旧版本
    • 使用 Redis 代理（如 Twemproxy）进行命令转换

Q2: 升级后出现性能下降 ​

原因：

  • 新版本的默认配置不适合当前业务场景
  • 新版本的某些特性导致性能下降
  • 兼容性问题

解决方案：

  1. 分析性能下降的具体原因
  2. 优化 Redis 配置
  3. 禁用不必要的新特性
  4. 如果问题无法解决，考虑回滚

Q3: 升级后数据丢失 ​

原因：

  • 升级过程中数据未正确持久化
  • 配置文件中的持久化参数设置不当
  • 版本兼容性问题

解决方案：

  1. 立即执行回滚操作
  2. 使用备份数据恢复
  3. 检查持久化配置
  4. 验证备份策略

Q4: Redis Cluster 升级后节点无法加入集群 ​

原因：

  • 节点配置文件中的集群配置不正确
  • 节点间的网络通信问题
  • 版本兼容性问题

解决方案：

  1. 检查节点配置文件
  2. 验证节点间的网络连通性
  3. 检查节点日志，确定具体错误
  4. 尝试重启节点
  5. 如果问题无法解决，考虑重新加入节点

Q5: 升级后应用程序无法连接 Redis ​

原因：

  • Redis 客户端库与目标版本不兼容
  • Redis 配置中的 bind 或 protected-mode 参数设置不当
  • 密码认证配置变更

解决方案：

  1. 检查应用程序日志，确定具体错误
  2. 更新 Redis 客户端库到兼容版本
  3. 检查 Redis 配置
  4. 验证密码认证配置

Q6: 如何处理 Redis 配置文件中的废弃参数？ ​

解决方案：

  1. 在升级前，查看目标版本的文档，了解废弃的参数
  2. 将废弃的参数替换为新的参数
  3. 如果没有直接替换的参数，可以删除该参数，使用默认值
  4. 测试环境中验证新的配置文件

常见问题（FAQ） ​

Q1: Redis 升级前需要做哪些准备工作？ ​

A1: Redis 升级前需要做以下准备工作：

  1. 版本兼容性检查，包括 Redis 版本和客户端兼容性
  2. 制定详细的升级计划，选择合适的升级方式
  3. 执行全量数据备份并验证备份完整性
  4. 准备测试环境进行升级验证
  5. 下载并编译目标版本

Q2: 不同部署架构的升级顺序是什么？ ​

A2: 不同部署架构的升级顺序如下：

  • 单机模式：直接升级
  • 主从复制：先升级从节点，再升级主节点
  • Redis Sentinel：先升级 Sentinel 节点，再升级从节点，最后升级主节点
  • Redis Cluster：滚动升级，一次升级一个节点

Q3: 什么时候需要执行回滚操作？ ​

A3: 当出现以下情况时应执行回滚操作：

  • 升级后出现严重的性能问题
  • 应用程序无法正常连接 Redis
  • 数据丢失或损坏
  • 出现大量错误日志
  • 无法解决的兼容性问题

Q4: 如何确保升级过程中的数据安全？ ​

A4: 确保升级过程中数据安全的措施包括：

  • 升级前执行全量备份并验证备份完整性
  • 采用滚动升级方式，避免服务中断
  • 先升级从节点，再升级主节点
  • 升级过程中实时监控数据状态
  • 准备完善的回滚方案

Q5: 如何选择合适的 Redis 版本进行升级？ ​

A5: 选择合适的 Redis 版本应考虑：

  • 选择经过充分测试的稳定版本
  • 优先选择 Redis 官方提供长期支持的版本
  • 跳过有已知严重 bug 的版本
  • 考虑与现有客户端库的兼容性

Q6: Redis Cluster 升级需要注意什么？ ​

A6: Redis Cluster 升级需要注意：

  • 采用滚动升级方式，一次升级一个节点
  • 先升级从节点，再升级主节点
  • 升级过程中监控集群状态
  • 验证节点升级后的状态
  • 确保集群在升级过程中保持可用