Master discovery frequency

[abdhx]

Hello 👋,

I am using the Redis-py package to connect to a Redis cluster with Sentinel. I have a question about the best practice for discovering the master node.

Should I:

1. Use sentinel.master_for each time I execute a command to ensure I'm always talking to the current master?

2. Discover the master once at startup and cache it, only re-discovering it periodically or upon errors? Do you have an example for this case?

Thank you for your help!

[petyaslavova]

Hi @abdhx , apologies for the late response! I'll look at your question tomorrow.

[petyaslavova]

Hi @abdhx,
The best approach depends on your use case:

• If you're working with a high-throughput application, it's better to cache the master and handle failover in your code (Option 2). This reduces the overhead of querying Sentinel and creating new client on every command.
• If performance is not a priority, you can stick with Option 1, where you discover the master for each command. This simplifies implementation, as you won’t need additional logic for caching and reconnection in case of failover.

Let me know if you need further clarification!

[abdhx]

Hello @petyaslavova,

I've conducted a test with a real failover scenario. During this test, I called sentinel.master_for only once at application startup, which returned a redis instance.

Remarkably, after the failover, the Redis instance automatically rediscovered the master without requiring any custom cache code on my part. This auto reconnection behavior was not initially considered in my question, as I was unaware that the returned Redis object includes it.

This behavior is cool and it's the solution to my issue, but is it intended? is it thread safe? I couldn't find this specifically outlined in the documentation.

Thank you! ❤

[petyaslavova]

Hi @abdhx, the discovery and establishment connection to the new master happen when we try to get a new connection from the connection pool - we have a validation that this connection is operational - in case of failover the connection we have is not operational and ConnectionError is raised (and catched) - in this case, we have a logic to disconnect the current connection and connect again - for sentinel client the connect process goes through discovering the current master and connecting to it.
I see that connect retries have been added without any documentation changes. Probably that's why you haven't found it specifically mentioned - I'll check what we have in the docs and update it according to the behavior.

[abdhx]

Thank you.