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

Number of master nodes #93

Open
SS-TruMinds opened this issue May 20, 2022 · 3 comments
Open

Number of master nodes #93

SS-TruMinds opened this issue May 20, 2022 · 3 comments

Comments

@SS-TruMinds
Copy link

SS-TruMinds commented May 20, 2022

Kindly help with the following queries:

  1. Is there a way to figure out the number of master nodes at any given point?
  2. Is there a way to figure out the number of active nodes (master + replica) nodes at any given point?

Thank you.

@bjosv
Copy link
Collaborator

bjosv commented May 25, 2022

There is no API for getting this information, but it would be possible to get this kind of knowledge from the internals via the context. The risk of doing it is that the internals might change though..

The known master nodes could be inspected via an async cluster context, and the number of known master nodes would be:
dictSize(acc->cc->nodes).

To check which are active you would need to check the state of them (via a cluster_node's con or acon).

Replica information is only kept when configured to do so. It can be enabled via redisClusterSetOptionParseSlaves(..) and the replica node information is kept in its master cluster_node (see slaves in the struct cluster_node).
You would need to check the state of the replica-nodes in the same way as for the masters.

If you have ideas of an API we are happy to get a draft or even a proposal via a PR :)

@SS-TruMinds
Copy link
Author

Thank you very much for the helpful information.

To elaborate further, we have the following requirements from our applications:

  1. inform me when at least one connection is available
  2. inform me when no connections are available

The first one is easy at least when we create the connection - we inform the application from the first connect callback. We also keep track of all the masters from which we receive all the connect callbacks.
Second part is a bit tricky as disconnect callbacks don't match against the connect callbacks. We can knock off the known masters on the basis of disconnect callbacks, but their slaves would now become masters so it's actually not a loss of master in a sense.

We will use the trick you mentioned above to inspect the state of known masters. Hopefully this gets updated based on the run-time state of the cluster?

Thank you again for all the help. Yes we will certainly look at the possibility of a PR once we have a better understanding.

@SS-TruMinds
Copy link
Author

A follow-up on this issue.

We have noticed that the master nodes do not get updated dynamically.
eg. if Master1 process dies & Slave1 takes it's place in the cluster, the list of master nodes held inside the cluster context does not get updated.
As a result, if we lose the masters registered at the context creation time, we can no longer communication with the cluster even if it is still up.

Please advice if there is a way to update the masters depending on the runtime status of the cluster?

Thank you.

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

No branches or pull requests

2 participants