如何配置Redis Sentinel使恢复的原主节点自动重回主节点？

是的，完全可以通过Redis Sentinel的配置实现你想要的效果——让恢复后的原Master自动重新成为集群的Master节点，而且你现有的配置已经做了最关键的铺垫，只需要理解背后的逻辑并确认几个细节就行。

核心逻辑：利用slave-priority控制Master优先级 #

你已经给两台Redis节点设置了不同的slave-priority参数：

• Server1（原Master）的slave-priority为10
• Server2的slave-priority为20

Redis Sentinel在选择新Master时，会优先挑选slave-priority数值更低的节点（数值越小，优先级越高）。这就是实现自动切回的核心依据——当原Master恢复后，Sentinel会识别到它是优先级更高的可用节点，进而触发故障转移把它重新提升为Master。

确认现有配置的有效性 #

你的Sentinel配置已经满足基础要求：

# 你的Sentinel核心配置
sentinel monitor q-redis-01 192.168.1.10 6379 2
sentinel down-after-milliseconds q-redis-01 10000
sentinel auth-pass q-redis-01 XXX

• quorum=2：需要至少2个Sentinel节点确认节点不可达才会触发故障转移，这个设置能保证决策的可靠性。
• down-after-milliseconds=10000：节点被判定为不可用的超时时间，符合常规故障检测需求。
• 你也配置了auth-pass，确保Sentinel能正常认证并控制Redis节点，这很重要。

另外，Redis Sentinel默认会自动检测高优先级的可用节点并触发故障转移，你不需要额外修改核心配置，但可以根据需求调整failover-timeout（默认180000ms，即3分钟）——这个参数控制故障转移的超时时间，保持默认即可。

原Master恢复后的自动流程 #

当Server1恢复上线后，Sentinel会按以下步骤自动操作：

1. 检测到Server1已恢复可用，并且它的slave-priority（10）远低于当前Master Server2的（20）。
2. 先将Server1设置为Server2的Slave，让它同步最新的数据，确保数据一致性（这一步是必须的，避免切回后出现数据差异）。
3. 数据同步完成后，Sentinel触发自动故障转移，将Server1重新提升为Master，同时把Server2切换为Server1的Slave。

测试验证方法 #

为了确保这个逻辑正常工作，你可以手动模拟故障场景：

1. 停止Server1的Redis服务，等待10秒左右（对应你设置的down-after-milliseconds），查看Sentinel日志确认Server2被提升为Master。
2. 重新启动Server1的Redis服务，观察Sentinel日志（/var/log/redis/redis-sentinel.log），你会看到类似「Starting failover for master q-redis-01」的日志，最终Server1会重新成为Master。
3. 如果没有自动触发，检查以下几点：
   • 所有Sentinel节点是否能通过VPN正常访问Server1和Server2。
   • Redis节点的masterauth和requirepass配置是否完全一致，避免认证失败导致Sentinel无法控制节点。
   • 查看Sentinel日志中的错误信息，定位具体问题。

注意事项 #

• 这个逻辑完全适配你的场景：因为你的架构仅用于故障转移而非扩容，优先让靠近核心基础设施的FRA节点作为Master，既满足性能需求，又保证了故障后的自动恢复能力。
• 确保VPN网络稳定，所有Sentinel和Redis节点之间的通信无延迟或中断，否则会影响Sentinel的状态检测。

内容的提问来源于stack exchange，提问作者Ivan Drinchev