-
Notifications
You must be signed in to change notification settings - Fork 2.6k
Dynamically route commands to master or replica #3591
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Hi @travisofthenorth, currently the only option for your issue is to have two clients - one with a load balancing strategy introduced recently - that will allow you to execute reads from replicas with three different strategies supported and one for the read commands that should not go to replicas. It sounds like an interesting idea for a new feature, but I can't provide any estimate of when it could be implemented. |
@petyaslavova thank you. I'll take a look. Just to clarify, I'm not looking to send a subset of Redis commands to replicas. Essentially I want to enable/disable The problem is pretty simply that the client has a single global config. If it could be controlled on a per-command basis, it would be solved. Pseudo-code:
|
@travisofthenorth thanks for the clarification :) - I have understood your question correctly. |
@petyaslavova thanks for all your help. I'm curious if you'd be interested in a change like this: #3598 I'm happy to keep going with this if the interface makes sense to you and is something you'd want to support. If not, I'll just close it. Let me know. |
Hello. I'm trying to understand if there's any way to programmatically send a command to a replica node using a
RedisCluster
. I'm aware of theread_from_replicas
configuration, but there are a few issues:read_from_replicas=True
and one that usesread_from_replicas=False
. However, now every process in my fleet has 2 connections to every node, doubling overall connections. For a large fleet, this is a problem as you can easily exceed the max number of connections.Is there any workaround for this? If not, is it something you'd be open to supporting in future versions?
The text was updated successfully, but these errors were encountered: