客户如何在哨兵故障转移后发现新主人？

To find the new master after a Redis Sentinel failover, clients must use a Sentinel-aware library, provide Sentinel addresses and the master group name, detect connection breaks to re-query Sentinels, optionally listen to pub/sub events like +switch-master, and carefully manage DNS or proxy layers that may affect discovery. Modern client libraries such as redis-py or ioredis support these features by querying Sentinels for the current master address, reconnecting automatically after failover, and staying updated through internal mechanisms or event notifications. Additionally, when using proxies or DNS layers, ensure they dynamically update based on Sentinel announcements to avoid connection delays to the new master.

When a Redis Sentinel failover happens, the client needs to find out who the new master is so it can keep reading and writing data. The good news is that Redis Sentinel handles most of this automatically — but only if your client is set up correctly.

Here’s how it typically works from a client's perspective:

Use a Sentinel-aware client library

Most modern Redis client libraries (like redis-py for Python or ioredis for Node.js) have built-in support for Redis Sentinel. These clients are designed to talk to Sentinel instances to discover the current master.

What you do as a developer is simply tell the client:

• The list of Sentinel addresses
• The name of the master group (e.g., mymaster)

Once configured, the client will ask any available Sentinel:
"Hey, who is the current master for 'mymaster'?"

The Sentinel responds with the current master address, and the client connects to it.

If a failover occurs and the master changes, the client usually detects that its connection is broken and re-queries Sentinel for the new master.

Tip: Make sure the client supports auto-discovery and reconnects after detecting failures. Otherwise, it might keep trying to connect to the old master indefinitely.

Sentinels monitor and announce the new master

Redis Sentinel doesn’t just detect failures — it also promotes a new slave to be the master and tells everyone about it.

After a failover:

1. One of the Sentinels gets elected to coordinate the failover.
2. It picks a healthy slave and turns it into the new master.
3. Other Sentinels learn about this change and update their internal state.
4. Any client that asks them for the master will get the updated IP and port.

So from the client’s point of view, nothing really changes — it just asks Sentinel the same question again and gets the new answer.

Some clients can also listen for Sentinel pub/sub messages like +switch-master, which notify subscribers immediately when a new master is promoted. This helps reduce downtime compared to waiting for a timeout or failed connection attempt.

Handle DNS or proxy layers carefully

Some setups use a proxy (like HAProxy) or DNS layer in front of Redis to hide the complexity of master discovery from clients.

In these cases:

• The client connects to a fixed hostname or IP
• The proxy/DNS layer is responsible for routing traffic to the current master
• You need to make sure the proxy listens to Sentinel or regularly polls for master changes

This approach simplifies client logic, but adds another moving part to maintain.

Also, note that DNS-based solutions can suffer from caching delays — if the client caches the old IP for too long, it won't know the new master exists right away.

That’s basically how clients find the new master after a Sentinel failover. As long as your client library supports Sentinel and you've given it the right configuration, it should handle the rest on its own.

以上是客户如何在哨兵故障转移后发现新主人？的详细内容。更多信息请关注PHP中文网其他相关文章！