跳到主要内容

升级、迁移与故障排查

运维事故最危险的不是“不知道答案”，而是在没有证据时连续重启、删文件和改参数。本章提供一套固定排查顺序，并覆盖常见症状。

1. 五步排障法​

  1. 定义现象：哪些业务、实例、命令和时间段受影响；
  2. 保留现场：日志、INFO、慢日志、系统资源、最近变更；
  3. 缩小范围：客户端、网络、Redis、持久化、复制还是宿主机；
  4. 最小变更验证：优先在副本或预发验证；
  5. 恢复后复盘：时间线、根因、监控缺口和预防动作。
redis-cli PING
redis-cli INFO all > /tmp/redis-info-$(date +%s).txt
redis-cli SLOWLOG GET 128 > /tmp/redis-slowlog-$(date +%s).txt
redis-cli LATENCY LATEST
sudo journalctl -u redis --since '30 minutes ago' --no-pager
free -h
df -h
ss -lntp | grep 6379

2. Redis 无法启动​

sudo systemctl status redis --no-pager
sudo journalctl -u redis -n 200 --no-pager
redis-server --test-memory 10

依次检查：配置语法和路径、数据/日志目录权限、端口占用、磁盘/inode、RDB/AOF 加载错误、内存不足。不要直接删除 dump.rdb 或 AOF；先复制到安全目录，再在副本上运行检查工具。

3. 客户端无法连接​

ss -lntp | grep 6379
redis-cli -h 127.0.0.1 -p 6379 PING
redis-cli -h <私网IP> -p 6379 PING

本机能连、远程不能连通常检查 bind、防火墙、安全组和路由；TCP 能连但认证失败检查 ACL 用户、密码、TLS CA 和证书域名；连接间歇失败检查连接池、DNS、NAT 和 maxclients。

4. 内存持续增长或写入 OOM​

redis-cli INFO memory
redis-cli INFO keyspace
redis-cli INFO stats | grep evicted_keys
redis-cli --bigkeys

常见原因：缓存没有 TTL、业务 key 数增长、BigKey、碎片、复制/AOF 缓冲、fork COW。先判断 used_memory_dataset 还是 RSS 增长，再决定清理、拆 key、调 TTL 或扩容。不要看到 OOM 就立即把 maxmemory 调到物理内存上限。

5. CPU 高或响应慢​

redis-cli SLOWLOG GET 50
redis-cli LATENCY DOCTOR
redis-cli INFO commandstats
redis-cli INFO persistence
top -H -p "$(pidof redis-server)"

检查慢命令、HotKey、Lua、批量响应、AOF/RDB、THP、宿主机 steal 和网络。慢日志为空不代表 Redis 没延迟，因为网络排队、fork 和系统调度不一定进入慢日志。

6. 主从同步失败​

redis-cli INFO replication
redis-cli ROLE
sudo journalctl -u redis --since '30 minutes ago' --no-pager

关注 master_link_status、last IO、offset、认证、网络、磁盘和副本重启。反复全量同步通常说明 backlog 不够、链路不稳、主节点无法生成 RDB或副本加载失败。

7. Sentinel 不切换​

redis-cli -p 26379 SENTINEL master mymaster
redis-cli -p 26379 SENTINEL ckquorum mymaster
redis-cli -p 26379 SENTINEL sentinels mymaster

确认有足够 Sentinel、quorum 可达、时钟和网络正常、认证正确。即使 Sentinel 已切换，应用若写死旧主地址仍会表现为不可用。

8. Cluster 状态异常​

redis-cli -c CLUSTER INFO
redis-cli -c CLUSTER NODES
redis-cli --cluster check <任一节点IP>:6379

检查 slot 缺失、fail/pfail、bus 端口、announce 地址和副本覆盖。不要在拓扑不清楚时执行 CLUSTER RESET、ADDSLOTS 或手工改 nodes.conf。

9. 升级前后的完整流程​

升级前​

  • 阅读目标版本发行说明和不兼容变更；
  • 验证客户端、模块、Exporter、RDB/AOF；
  • 完成备份和恢复演练；
  • 记录基线与回滚版本；
  • 在预发使用真实数据规模压测。

滚动升级​

Sentinel 架构先升级副本，确认复制正常后受控切主，再升级旧主。Cluster 每次只处理一个节点，确保它的副本健康，避免同一复制组同时下线。

升级后​

验证版本、角色、复制、持久化、慢日志、错误率、P99 和数据抽样。观察完整业务周期后才结束变更。

10. 迁移服务器或机房​

可选方案包括建立新副本、Cluster reshard、专用迁移工具或应用双写。选择取决于数据量、写入速率、RPO/RTO 和是否允许停机。

切流前确认：

  1. 新旧实例数据量、抽样 key、TTL 和复制 offset；
  2. DNS TTL、客户端拓扑缓存和连接池刷新；
  3. 新环境 ACL/TLS、监控、备份和容量；
  4. 双写期间的冲突与回放规则；
  5. 明确回滚窗口，避免新旧两边同时接受无序写入。

11. 生产验收清单​

  • 架构与 RPO/RTO 匹配；
  • maxmemory、淘汰策略和写满降级已压测；
  • Redis 不暴露公网，ACL/TLS 和密钥轮换已落实；
  • Sentinel/Cluster 跨故障域并完成切换演练；
  • RDB/AOF、异地备份和恢复演练有记录；
  • Prometheus、Grafana、告警和运行手册已上线；
  • BigKey/HotKey、慢命令和容量趋势纳入巡检；
  • 升级、迁移、扩缩容和回滚经过演练；
  • 危险命令和在线清理有审批、审计与复盘。