Skip to content
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

[NEW] Support node discovery in standalone (cluster mode disabled) #1749

Open
asafpamzn opened this issue Feb 18, 2025 · 6 comments
Open

[NEW] Support node discovery in standalone (cluster mode disabled) #1749

asafpamzn opened this issue Feb 18, 2025 · 6 comments
Labels
client-changes-needed Client changes are required for this feature

Comments

@asafpamzn
Copy link

The problem/use-case that the feature addresses

In cluster mode clusters the clients gets the topology using one of the cluster commands. The ask is to create a similar command for standalone clusters.

It will simplify the usage for users that works in standalone but have dynamic number of replicas. That is, during the life time of the cluster they delete and adds replicas

Description of the feature

Implement new command to get the topology of standalone cluster.

Alternatives you've considered

Migrate to cluster mode enable, but it cannot cover all use cases.

Additional information

Any additional information that is relevant to the feature request.

@asafpamzn asafpamzn added the client-changes-needed Client changes are required for this feature label Feb 18, 2025
@hpatro
Copy link
Collaborator

hpatro commented Feb 18, 2025

It would be nice to capture what are the steps used by the clients currently in standalone setup? Is the information currently built via INFO REPLICATION on the primary ? And what are the shortcomings with it?

@asafpor
Copy link

asafpor commented Feb 18, 2025

Usually clients just get the endpoints as parameters and do not discover the nodes.

If there is an option to get via replication info we can guide client maintainer to use it. Is the info replication avaliable in elasticache and other valkey providers?

@hpatro
Copy link
Collaborator

hpatro commented Feb 19, 2025

Thought about it a bit more, I guess what is missing at this point is passing around the hostname information in standalone mode. In cluster mode, we use the cluster bus to gossip that information. if the replica setup was performed via REPLICAOF ip port, it might not be enough information for client to use and connect to.

@asafpamzn
Copy link
Author

@hpatro. "Thought about it a bit more,"
is (It == my request for "cluster nodes" in standalone.)
Or (it == INFO REPLICATION)

?

@hpatro
Copy link
Collaborator

hpatro commented Feb 19, 2025

@asafpamzn around your request and what is lacking.

"I guess what is missing at this point is passing around the hostname information in standalone mode. In cluster mode, we use the cluster bus to gossip that information. if the replica setup was performed via REPLICAOF ip port, it might not be enough information for client to use and connect to."

@asafpor
Copy link

asafpor commented Feb 22, 2025

@madolson , is that something that we can prioritize.
On one hand we want users to move to CME.
On the other hand. We need this feature in order to support read from replica at CMD. It will allow to client to hold all replicas endpoints.

I think that it is a quick win. See
valkey-io/valkey-glide#3091

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
client-changes-needed Client changes are required for this feature
Projects
None yet
Development

No branches or pull requests

3 participants