Redis 手动故障转移

手动故障转移是指在Redis集群或主从架构中，管理员主动将主节点切换到从节点的操作。与自动故障转移不同，手动故障转移由管理员在计划维护或预见到潜在问题时主动执行，确保服务连续性和数据完整性。

适用场景

主节点计划维护（如硬件升级、系统补丁安装）
主节点性能下降，需要切换到更强大的从节点
预见到主节点可能出现故障，提前进行切换
测试故障转移流程，验证系统可靠性
调整集群拓扑结构

优势与风险

优势	风险
可在维护窗口内执行，减少业务影响	操作不当可能导致数据丢失
可提前准备，降低切换风险	可能引起短时间的服务中断
可验证数据一致性后再切换	配置错误可能导致集群状态异常
适合计划性操作	需要管理员具备丰富的Redis运维经验

单实例Redis手动故障转移

单实例Redis指没有从节点的独立实例，手动故障转移主要涉及数据迁移和服务切换。

准备工作

备份当前主节点数据（RDB或AOF）
准备新的Redis实例，配置与原主节点一致
确保新实例有足够的硬件资源
通知相关业务团队，安排维护窗口

操作步骤

备份原主节点数据

bash

# 生成RDB快照
redis-cli -h old-master -p 6379 bgsave

# 等待快照生成完成
redis-cli -h old-master -p 6379 LASTSAVE

将备份文件复制到新实例

bash

scp /var/lib/redis/dump.rdb new-master:/var/lib/redis/

启动新实例
bash
```
systemctl start redis
```

验证新实例数据完整性

bash

# 比较键数量
OLD_KEY_COUNT=$(redis-cli -h old-master -p 6379 DBSIZE)
NEW_KEY_COUNT=$(redis-cli -h new-master -p 6379 DBSIZE)

if [ "$OLD_KEY_COUNT" -eq "$NEW_KEY_COUNT" ]; then
    echo "数据完整性验证通过"
else
    echo "数据完整性验证失败"
    exit 1
fi

切换业务流量
- 更新负载均衡配置，将流量导向新实例
- 或更新应用配置，连接到新实例
验证业务正常运行
- 检查应用日志
- 执行基本的读写操作验证

主从架构手动故障转移

主从架构中，手动故障转移涉及将从节点提升为主节点，并重新配置其他从节点。

准备工作

检查主从复制状态
确保从节点数据与主节点同步
备份主节点关键配置
准备切换工具（如redis-cli）

操作步骤

检查主从复制状态

bash

# 检查主节点信息
redis-cli -h master -p 6379 info replication

# 检查从节点同步状态
redis-cli -h slave1 -p 6379 info replication | grep -E "role|master_host|master_link_status|slave_repl_offset"

选择合适的从节点
- 优先选择数据同步最完整的从节点
- 考虑从节点的硬件性能和网络状况
- 选择与主节点网络延迟较低的从节点

停止从节点的复制

bash

redis-cli -h slave1 -p 6379 slaveof no one

验证从节点成为主节点

bash

redis-cli -h slave1 -p 6379 info replication | grep role

将其他从节点指向新主节点

bash

redis-cli -h slave2 -p 6379 slaveof new-master 6379
redis-cli -h slave3 -p 6379 slaveof new-master 6379

验证所有从节点同步状态

bash

for slave in slave1 slave2 slave3; do
    redis-cli -h $slave -p 6379 info replication | grep -E "role|master_host|master_link_status"
done

切换业务流量
- 更新应用配置或负载均衡指向新主节点
监控新主节点性能
- 检查CPU、内存使用率
- 监控命令执行延迟
- 观察网络流量

Redis Sentinel手动故障转移

Redis Sentinel提供了自动故障转移功能，同时也支持手动触发故障转移，确保在计划维护时可以安全地进行主从切换。

准备工作

确保Sentinel集群正常运行（至少3个实例）
检查Sentinel配置，确认监控的主节点
备份Sentinel配置文件
准备redis-cli工具

操作步骤

检查Sentinel状态

bash

# 检查Sentinel监控的主节点
redis-cli -h sentinel1 -p 26379 sentinel masters

# 检查Sentinel集群状态
redis-cli -h sentinel1 -p 26379 sentinel replicas mymaster

触发手动故障转移

bash

redis-cli -h sentinel1 -p 26379 sentinel failover mymaster

监控故障转移过程

bash

# 实时查看Sentinel日志
tail -f /var/log/redis/sentinel.log

验证故障转移结果

bash

# 检查新的主节点
redis-cli -h sentinel1 -p 26379 sentinel get-master-addr-by-name mymaster

# 检查所有Sentinel是否达成一致
for sentinel in sentinel1 sentinel2 sentinel3; do
    redis-cli -h $sentinel -p 26379 sentinel get-master-addr-by-name mymaster
done

验证数据完整性

bash

# 比较故障转移前后的键数量
OLD_KEY_COUNT=$(redis-cli -h old-master -p 6379 DBSIZE)
NEW_KEY_COUNT=$(redis-cli -h new-master -p 6379 DBSIZE)

if [ "$OLD_KEY_COUNT" -eq "$NEW_KEY_COUNT" ]; then
    echo "数据完整性验证通过"
else
    echo "数据完整性验证失败"
fi

验证业务正常运行
- 检查应用连接状态
- 执行读写操作验证

Redis Cluster手动故障转移

Redis Cluster是分布式架构，手动故障转移涉及将主节点的哈希槽迁移到从节点，并更新集群状态。

准备工作

确保集群状态正常（所有节点在线，哈希槽分配完整）
检查主从复制状态
备份集群配置
准备redis-cli工具

操作步骤

检查集群状态

bash

redis-cli -h node1 -p 6379 cluster info
redis-cli -h node1 -p 6379 cluster nodes

选择要切换的主从节点对
- 确定要切换的主节点ID（master-id）
- 找到其对应的从节点ID（slave-id）

在从节点上触发手动故障转移

bash

redis-cli -h slave-node -p 6379 cluster failover

或使用带参数的命令：

bash

# 强制故障转移，不等待数据同步
redis-cli -h slave-node -p 6379 cluster failover force

#  takeover模式，用于原主节点无法访问的情况
redis-cli -h slave-node -p 6379 cluster failover takeover

监控故障转移过程

bash

# 实时查看集群节点状态变化
watch -n 1 redis-cli -h node1 -p 6379 cluster nodes

验证故障转移结果

bash

# 检查集群状态
redis-cli -h node1 -p 6379 cluster info

# 检查节点角色变化
redis-cli -h node1 -p 6379 cluster nodes | grep -E "master|slave"

# 检查哈希槽分配
redis-cli -h node1 -p 6379 cluster slots

验证数据完整性

bash

# 检查集群中键的数量
redis-cli -c -h node1 -p 6379 DBSIZE

验证业务正常运行
- 执行跨哈希槽的读写操作
- 检查应用连接状态
- 监控集群性能指标

手动故障转移最佳实践

预操作准备

制定详细的操作计划：包括步骤、时间窗口、回滚方案
通知相关团队：提前告知业务、开发、运维团队
备份关键数据：在操作前备份主节点数据
验证监控系统：确保监控能实时反映集群状态
准备回滚方案：制定详细的回滚步骤，以备不时之需

操作过程中的注意事项

选择合适的维护窗口：尽量在业务低峰期执行
严格按照操作步骤执行：避免跳过或简化步骤
实时监控系统状态：密切关注Redis日志、监控指标
验证每一步的结果：确保前一步成功后再执行下一步
记录操作过程：详细记录每一步操作和结果，便于后续分析

操作后的验证

验证集群状态：确保所有节点在线，角色正确
验证数据完整性：比较故障转移前后的数据量
验证业务连续性：检查应用是否正常连接和操作
监控系统性能：观察CPU、内存、网络等指标
更新文档：记录本次操作的详细信息，包括原因、步骤、结果

回滚方案

主从架构回滚：将原主节点重新设置为主节点，其他从节点指向它
Sentinel架构回滚：使用Sentinel failover命令重新切换回原主节点
Cluster架构回滚：在新的从节点（原主节点）上执行cluster failover命令

常见问题与解决方案

故障转移后数据丢失

问题描述：手动故障转移后，发现部分数据丢失。

可能原因：

从节点数据与主节点不同步
故障转移过程中主节点仍在写入数据
网络延迟导致数据未及时复制

解决方案：

故障转移前确保从节点与主节点数据同步
执行故障转移前，可暂时停止写入操作
使用wait命令确保数据复制完成：redis-cli -h master -p 6379 wait 1 0
启用AOF持久化，并设置合适的fsync策略

故障转移后集群状态异常

问题描述：手动故障转移后，集群状态显示异常，部分节点离线或哈希槽分配错误。

可能原因：

操作过程中节点意外重启
网络连接中断
节点配置错误

解决方案：

检查所有节点的网络连接
重启异常节点
使用cluster meet命令重新加入节点
使用cluster fix命令修复集群状态

故障转移过程超时

问题描述：手动故障转移命令执行超时，未完成切换。

可能原因：

主节点负载过高，无法及时响应
网络延迟较大
数据量过大，同步时间长

解决方案：

在业务低峰期执行故障转移
确保网络连接稳定
考虑先扩容从节点硬件，提高同步速度
对于大数据量场景，可考虑分批迁移

故障转移后应用连接失败

问题描述：手动故障转移后，应用无法连接到新的主节点。

可能原因：

应用配置未更新
新主节点的防火墙规则限制
新主节点的maxclients设置过小
新主节点的bind地址配置错误

解决方案：

更新应用配置，指向新主节点
检查并调整防火墙规则
增加新主节点的maxclients配置
确保新主节点的bind地址允许应用访问

不同Redis版本的差异

Redis 3.x与4.x的差异

Redis 3.x的Cluster手动故障转移需要使用cluster failover命令
Redis 4.x新增了cluster failover force和cluster failover takeover命令，提供更灵活的故障转移选项
Redis 4.x优化了故障转移的性能和可靠性

Redis 5.x的改进

Redis 5.x增强了Sentinel的故障转移功能，支持更多的配置选项
优化了Cluster故障转移的算法，减少了切换时间
新增了cluster failover命令的进度反馈

Redis 6.x的新特性

Redis 6.x支持多线程I/O，提高了故障转移过程中的处理能力
增强了Cluster的监控和管理功能
新增了ACL（访问控制列表），故障转移过程中需要注意权限配置

自动化工具与脚本

自动化脚本示例

以下是一个简单的Redis主从架构手动故障转移脚本：

bash

#!/bin/bash

# 配置参数
OLD_MASTER="old-master"
NEW_MASTER="new-master"
PORT=6379
OTHER_SLAVES=("slave2" "slave3")

# 检查新主节点复制状态
echo "检查新主节点复制状态..."
SLAVE_STATUS=$(redis-cli -h $NEW_MASTER -p $PORT info replication | grep master_link_status | cut -d: -f2)
if [ "$SLAVE_STATUS" != "up" ]; then
    echo "错误：新主节点与原主节点复制连接断开"
    exit 1
fi

# 停止从节点复制
echo "停止新主节点的复制..."
redis-cli -h $NEW_MASTER -p $PORT slaveof no one

# 验证新主节点
echo "验证新主节点状态..."
ROLE=$(redis-cli -h $NEW_MASTER -p $PORT info replication | grep role | cut -d: -f2)
if [ "$ROLE" != "master" ]; then
    echo "错误：新主节点角色设置失败"
    exit 1
fi

# 其他从节点指向新主节点
echo "将其他从节点指向新主节点..."
for slave in "${OTHER_SLAVES[@]}"; do
    redis-cli -h $slave -p $PORT slaveof $NEW_MASTER $PORT
    echo "  已将 $slave 指向 $NEW_MASTER"
done

# 验证所有从节点
echo "验证所有从节点状态..."
for slave in "${OTHER_SLAVES[@]}"; do
    STATUS=$(redis-cli -h $slave -p $PORT info replication | grep -E "role|master_host|master_link_status")
    echo "  $slave 状态：$STATUS"
done

echo "手动故障转移完成！"

第三方工具

Redis Admin GUI：如RedisInsight、Another Redis Desktop Manager等，提供可视化的故障转移操作
Ansible：可编写Playbook自动化Redis故障转移流程
Terraform：适用于云环境中Redis实例的故障转移自动化
Kubernetes：使用StatefulSet管理Redis集群，可通过更新Service实现故障转移

监控与告警

故障转移过程监控

监控指标：主从复制延迟、命令执行时间、内存使用率、CPU使用率
日志监控：实时查看Redis和Sentinel日志，关注故障转移相关信息
集群状态：使用cluster info和cluster nodes命令监控集群状态

告警设置

复制延迟告警：当从节点复制延迟超过阈值时触发告警
节点离线告警：当节点离线时立即通知管理员
主节点切换告警：当主节点发生变化时触发告警
内存使用率告警：当内存使用率超过阈值时告警

事后分析

分析故障转移过程中的日志，找出优化点
统计故障转移的耗时，评估切换效率
检查数据完整性，确认是否有数据丢失
总结经验教训，完善故障转移流程

常见问题（FAQ）

Q1: 手动故障转移和自动故障转移有什么区别？

A1: 手动故障转移由管理员主动执行，通常在计划维护或预见到问题时进行，可控制切换时间和流程。自动故障转移由Redis Sentinel或Cluster自动触发，当检测到主节点故障时立即执行，用于处理突发故障。

Q2: 执行手动故障转移前需要停止写入操作吗？

A2: 建议在执行手动故障转移前，暂时停止写入操作或在业务低峰期执行，以确保数据完整性。如果无法停止写入，可使用wait命令确保数据复制到从节点后再执行切换。

Q3: 如何选择合适的从节点进行故障转移？

A3: 应选择数据同步最完整、硬件性能较好、网络延迟较低的从节点。可通过查看master_link_status、slave_repl_offset等指标来评估从节点状态。

Q4: 手动故障转移可能导致多长时间的服务中断？

A4: 服务中断时间取决于Redis版本、集群规模和网络状况。在优化良好的环境中，Sentinel手动故障转移通常耗时1-5秒，Cluster手动故障转移耗时5-10秒。

Q5: 如何验证故障转移后的数据完整性？

A5: 可通过比较故障转移前后的键数量（使用DBSIZE命令）、执行特定键的查询验证、或使用Redis的check-aof和check-rdb工具验证数据文件完整性。

Q6: 故障转移后需要更新哪些配置？

A6: 需要更新应用配置或负载均衡配置，指向新的主节点；如果使用了监控系统，需要更新监控配置；对于Sentinel架构，无需手动更新Sentinel配置，它会自动发现新的主节点。

Q7: 什么情况下适合使用强制故障转移？

A7: 强制故障转移（cluster failover force）适用于原主节点无法访问，且需要尽快恢复服务的情况。但使用强制故障转移可能导致数据丢失，应谨慎使用。

Q8: 如何回滚手动故障转移操作？

A8: 回滚方法取决于Redis架构：

主从架构：将原主节点重新设置为主节点，其他从节点指向它
Sentinel架构：使用SENTINEL failover命令重新切换回原主节点
Cluster架构：在新的从节点（原主节点）上执行cluster failover命令

Q9: 手动故障转移需要多少个Sentinel节点？

A9: 建议至少部署3个Sentinel节点，以确保在部分节点故障时仍能正常工作。手动故障转移需要大多数Sentinel节点达成一致才能执行。

Q10: 如何测试手动故障转移流程？

A10: 建议定期进行手动故障转移测试，验证系统可靠性和管理员操作熟练度。测试时应在非生产环境或业务低峰期进行，详细记录测试过程和结果，并根据测试情况优化故障转移流程。

Redis 手动故障转移 ​

适用场景 ​

优势与风险 ​

单实例Redis手动故障转移 ​

准备工作 ​

操作步骤 ​

主从架构手动故障转移 ​

准备工作 ​

操作步骤 ​

Redis Sentinel手动故障转移 ​

准备工作 ​

操作步骤 ​

Redis Cluster手动故障转移 ​

准备工作 ​

操作步骤 ​

手动故障转移最佳实践 ​

预操作准备 ​

操作过程中的注意事项 ​

操作后的验证 ​

回滚方案 ​

常见问题与解决方案 ​

故障转移后数据丢失 ​

故障转移后集群状态异常 ​

故障转移过程超时 ​

故障转移后应用连接失败 ​

不同Redis版本的差异 ​

Redis 3.x与4.x的差异 ​

Redis 5.x的改进 ​

Redis 6.x的新特性 ​

自动化工具与脚本 ​

自动化脚本示例 ​

第三方工具 ​

监控与告警 ​

故障转移过程监控 ​

告警设置 ​

事后分析 ​

常见问题（FAQ） ​

Q1: 手动故障转移和自动故障转移有什么区别？ ​

Q2: 执行手动故障转移前需要停止写入操作吗？ ​

Q3: 如何选择合适的从节点进行故障转移？ ​

Q4: 手动故障转移可能导致多长时间的服务中断？ ​

Q5: 如何验证故障转移后的数据完整性？ ​

Q6: 故障转移后需要更新哪些配置？ ​

Q7: 什么情况下适合使用强制故障转移？ ​

Q8: 如何回滚手动故障转移操作？ ​

Q9: 手动故障转移需要多少个Sentinel节点？ ​

Q10: 如何测试手动故障转移流程？ ​

Redis 手动故障转移

适用场景

优势与风险

单实例Redis手动故障转移

准备工作

操作步骤

主从架构手动故障转移

准备工作

操作步骤

Redis Sentinel手动故障转移

准备工作

操作步骤

Redis Cluster手动故障转移

准备工作

操作步骤

手动故障转移最佳实践

预操作准备

操作过程中的注意事项

操作后的验证

回滚方案

常见问题与解决方案

故障转移后数据丢失

故障转移后集群状态异常

故障转移过程超时

故障转移后应用连接失败

不同Redis版本的差异

Redis 3.x与4.x的差异

Redis 5.x的改进

Redis 6.x的新特性

自动化工具与脚本

自动化脚本示例

第三方工具

监控与告警

故障转移过程监控

告警设置

事后分析

常见问题（FAQ）

Q1: 手动故障转移和自动故障转移有什么区别？

Q2: 执行手动故障转移前需要停止写入操作吗？

Q3: 如何选择合适的从节点进行故障转移？

Q4: 手动故障转移可能导致多长时间的服务中断？

Q5: 如何验证故障转移后的数据完整性？

Q6: 故障转移后需要更新哪些配置？

Q7: 什么情况下适合使用强制故障转移？

Q8: 如何回滚手动故障转移操作？

Q9: 手动故障转移需要多少个Sentinel节点？

Q10: 如何测试手动故障转移流程？