Skip to content

Support subscriptions against cluster slave nodes #3480

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

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

LINKIWI
Copy link
Contributor

@LINKIWI LINKIWI commented Aug 16, 2025

Currently, SUBSCRIBE (and its sibling variant commands) establish connections only to masters, regardless of the ReadOnly option specified in client options.

This PR allows go-redis to respect the ReadOnly option for subscriptions in the pubsub client, by preferring slave nodes for new connections. Note that in both global and sharded pubsub modes, messages are replicated to slaves by Redis.

Note that newConn in the pubsub client is only used for creating connections for long-lived subscriptions, so it does not need to consider any per-command R/W-family properties as in the case for commands outside of the pubsub client.

I added a new unit test case for both global and sharded subscriptions with ReadOnly set to true, with an additional assertion on the value of pubsub{shard}_channels as returned by INFO to additionally verify that the subscription is served only by slave nodes.

@ndyakov
Copy link
Member

ndyakov commented Aug 16, 2025

Hello @LINKIWI, this is a nice addition, I am working on something that touches the pubsub at the moment and would like to hold merging your PR once I am done. Do you have a need for this / is is urgent to merge?

@LINKIWI
Copy link
Contributor Author

LINKIWI commented Aug 17, 2025

Hello @LINKIWI, this is a nice addition, I am working on something that touches the pubsub at the moment and would like to hold merging your PR once I am done. Do you have a need for this / is is urgent to merge?

Thanks for the review. No worries, it is not urgent; happy to hold for now and rebase on top of the in-progress refactor once that is in. Thanks!

@ndyakov ndyakov added wait Can’t be processed temporarily for other reasons feature labels Aug 18, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature wait Can’t be processed temporarily for other reasons
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants