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 for Sentinel commands #31

Open
therealbill opened this issue Jul 22, 2014 · 0 comments
Open

Support for Sentinel commands #31

therealbill opened this issue Jul 22, 2014 · 0 comments
Assignees
Milestone

Comments

@therealbill
Copy link

Redis now comes with several Sentinel commands such as:

"sentinel masters" -> list of pods (master+slaves) the sentinel constellation is managing where each master is a key/value sequence of pod-specific information.

"sentinel master " -> returns the information for a specific pod in the same format as the sentinel masters command

"sentinel slaves " -> a key/value sequence giving a list of slaves with per-slave information.

The command "sentinel master cache" (where "cache" is the name of a master being monitored by the sentinel). issued in the CLI will return data along the following format:

127.0.0.1:26379> sentinel master cache
 1) "name"
 2) "cache"
 3) "ip"
 4) "127.0.0.1"
 5) "port"
... remainder snipped for brevity

Including this in the library via a specific command would greatly increase this use case's simplicity.

However, moving to the command "sentinel masters" you get a list of the above entries:

127.0.0.1:26379> sentinel masters
1)  1) "name"
    2) "cache"
    3) "ip"
    4) "127.0.0.1"
    5) "port"
    ...
2) ....

This too should be parsed into a Struct by the library. Other sentinel commands have this same pattern.

For the Sentinel commands, there is a reason beyond user ease to build this into the library. In order to support Sentinel, and possibly Redis Cluster, the library will need to know this same information in order to select a master to write/read to/from or a collection of slaves to read from.

At an absolute minimum, defining the structs in the library and exporting them for the user to reference would be an improvement.

As far as the command names I'd start with a suggestion of something like

SentinelMaster(name string) -> returns a struct representing a MasterEntry
SentinelMasters() -> Returns a []MasterEntry
InfoStruct(section string) -> returns a Struct for the section given, unless "all" is the section in which case a [] of Structs or an InfoAllStruct which contains each section's struct in it. I suggest InfoStruct to avoid breaking the current Info interface.

@xiam xiam self-assigned this Dec 9, 2014
@xiam xiam added this to the next-release milestone Dec 9, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants