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

Support standalone Redis (non-cluster) #27

Open
zuiderkwast opened this issue Feb 22, 2023 · 7 comments
Open

Support standalone Redis (non-cluster) #27

zuiderkwast opened this issue Feb 22, 2023 · 7 comments
Labels
enhancement New feature or request

Comments

@zuiderkwast
Copy link
Collaborator

It is useful for developers if the same client can connect to a standalone node, not only a cluster. For this, we need to handle an error response form CLUSTER SLOTS and handle this as if the whole cluster is handled by a single node.

The requirement that the cluster needs to have at least two masters for 'cluster_ok' may need to be reconsidered.

@zuiderkwast zuiderkwast added the enhancement New feature or request label Nov 13, 2023
@ioolkos
Copy link

ioolkos commented May 27, 2024

@zuiderkwast is it possible to connect to a standalone node, with PR #41 ?

@zuiderkwast
Copy link
Collaborator Author

Even without #41, it's possible to connect to a single node using the ered_client module. #41 does make things a little more clear though with functions like ered:connect_client for connecting to a single instance.

It's not possible to use a standalone instance as if it were a cluster though, with the same functions, but actually I don't think we want to do this automatically. Cluster and standalone deployments are very different. Standalone mode allows SELECT and cross-slot commands, for example, which are forbidden in cluster mode.

@ioolkos
Copy link

ioolkos commented May 27, 2024

@zuiderkwast Thanks a lot for your useful information! Currently we're using eredis in VerneMQ so we cannot connect to a Redis cluster yet. And ered's stated goal is to replace both previous libraries, isn't it. In any case, I'll try to do some testing based on your suggestions.

@zuiderkwast
Copy link
Collaborator Author

zuiderkwast commented May 27, 2024

Yes, ered implements the functionality for single instance and cluster, but the API has a preference for cluster. This was done before I was the maintainer of this project. Now, I've been trying to make the API look nice for single instance too.

An idea: We use a tuple like {cluster, Pid} or {standalone, Pid} as the ered instance reference, returned by ered:connect functions. Then we can use the same functions like ered:command/N for both of them and it can dispatch to the right module based on the tuple. That's future work, if you like the idea. (ssl:connect and gen_tcp:connect return tuples like this, so it's not that strange.)

I've been busy with other work though.

@ioolkos
Copy link

ioolkos commented May 27, 2024

@zuiderkwast I suppose the client always knows whether it's connecting to a standalone or a cluster. Your suggestion sounds great to me, in any case!

@ioolkos
Copy link

ioolkos commented May 30, 2024

I've now written my plugin using ered:start_link/2 as main entry point. As expected, this only works for a cluster, not a standalone (standalone gets the unmapped_slots error). A question, though: with the idea proposed above, will ered be able to figure out by itself whether it connects to a standalone or a cluster?

@zuiderkwast
Copy link
Collaborator Author

A question, though: with the idea proposed above, will ered be able to figure out by itself whether it connects to a standalone or a cluster?

It would be possible to auto-detect, but I think it's better that users connect explicitly to cluster or standalone. I'm thinking ered:connect(Host, Port, Opts) for standalone and ered:connect_cluster(AddressesAndPorts, Opts) for cluster. After that, ered:command(EredRef, Command) and similar can be used for both kinds of instances.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants