Sentinel and slaves in INFO output
Tuesday, 26 June 12
As every Redis user patient enough to follow me on twitter knows, my focus is all on implementing Redis Sentinel lately, and I'm making good progresses. What we have right now is Sentinel implemented as a special mode of the normal Redis server (invoked using redis-server --sentinel or simply renaming redis-server executable into redis-sentinel), so I'm reusing everything was inside Redis, that's a big advantage in terms of development time, code reuse, stability.
Sentinel already implements the connection with all the masters and slaves monitored, the ability to ping instances, collect informations with INFO. You can query Sentinel using redis-cli, but it only accept a different set of commands, especially the SENTINEL command that can be used to get informations about the monitored masters and in general to inspect the Sentinel state.
Sentinel is conceived to be easy to setup. Like Redis itself, or Redis replication, I try hard to avoid that users need to read a lot of documentation or to perform boring tasks in order to use the system. One of the key points in making it non boring is that the configuration is easy, and consists mainly in the description of what masters to monitor.
Sentinels auto discover the other sentinels that are monitoring the same master using Redis Pub/Sub. But another important step is to auto discover slaves attached to master.
Redis already shows attached slaves in INFO output, but guess what, the port number exported was broken, and nobody noticed. Slaves were not listed with their own listening port but with the TCP port they used to connect (as clients) to the Redis master.
In order to fix this I introduced a new command called REPLCONFIG that is used to set some state before starting the replication, so now a slave does something like that when performing the first synchronization with a master:
This is useful for Sentinel, but also fixes the problem with master's INFO output. This way clients can discover slaves attached to a master, and their exact address and port, just by querying the master.
I hope to have more news about Sentinel soon.
Sentinel already implements the connection with all the masters and slaves monitored, the ability to ping instances, collect informations with INFO. You can query Sentinel using redis-cli, but it only accept a different set of commands, especially the SENTINEL command that can be used to get informations about the monitored masters and in general to inspect the Sentinel state.
redis 127.0.0.1:26379> sentinel masters 1) 1) "mymaster" 2) "127.0.0.1" 3) "6379" 4) "om" 5) "966" 6) "966" 7) "0"I lost almost two days in my schedule because sunday I was silly enough to take too much sun in a single day, getting a fever :) But now I'm back to work. So the idea is to have a beta of Sentinel as soon as possibly in order to get user feedback, probably in the first days of July (this was supposed to be end of June but probably I'll not be able to do that).
Sentinel is conceived to be easy to setup. Like Redis itself, or Redis replication, I try hard to avoid that users need to read a lot of documentation or to perform boring tasks in order to use the system. One of the key points in making it non boring is that the configuration is easy, and consists mainly in the description of what masters to monitor.
Sentinels auto discover the other sentinels that are monitoring the same master using Redis Pub/Sub. But another important step is to auto discover slaves attached to master.
Redis already shows attached slaves in INFO output, but guess what, the port number exported was broken, and nobody noticed. Slaves were not listed with their own listening port but with the TCP port they used to connect (as clients) to the Redis master.
In order to fix this I introduced a new command called REPLCONFIG that is used to set some state before starting the replication, so now a slave does something like that when performing the first synchronization with a master:
REPLCONFIG lisetning-port 6380 SYNCThis means that the new system is backward compatible, as we ignore errors returned by REPLCONFIG. Probably we'll use REPLCONFIG in the future to implement partial replication as well. Imagine something like REPLCONFIG lastoffset ...
This is useful for Sentinel, but also fixes the problem with master's INFO output. This way clients can discover slaves attached to a master, and their exact address and port, just by querying the master.
I hope to have more news about Sentinel soon.
Do you like this article?
Subscribe to the RSS feed of this blog or use the newsletter service in order to receive a notification every time there is something of new to read here.
Note: you'll not see this box again if you are a usual reader.
Subscribe to the RSS feed of this blog or use the newsletter service in order to receive a notification every time there is something of new to read here.
Note: you'll not see this box again if you are a usual reader.