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:
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.
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:
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:
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.