Remove slave from a sentinel

[Kevin Sołtysiak]

Hello,

here's the situation : I have 4 servers running redis, A, B, C and D: A is the master, B and C are slaves, and each of them are running an instance of sentinel. Everything's fine so far.

Now, D is our staging server. The administrator copied the config from B or C, turning D into a slave of A (which it should not be). I've tried changing the config of D, but the sentinels are rewriting D's config and turning into a slave everytime D's redis is restarted. Looking through sentinel and redis docs I can't find how to remove D from the sentinels. Anybody have a solution or an idea?

Thanks a lot for your time and your help !

[ora...@bistri.com]

Hi.

You should be able to find a line in your sentinel.conf file with the incriminated known-slave.
You can remove it and then restart the sentinel.

[Josiah Carlson]

The simplest answer is to shut down D, change its config to not be a slave, change its listening port to something else, then start it back up. The sentinels shouldn't be able to find it, and you should be able to use it from then on without issue.

 - Josiah

--
You received this message because you are subscribed to the Google Groups "Redis DB" group.
To unsubscribe from this group and stop receiving emails from it, send an email to redis-db+u...@googlegroups.com.
To post to this group, send email to redi...@googlegroups.com.
Visit this group at http://groups.google.com/group/redis-db.
For more options, visit https://groups.google.com/d/optout.

[The Baldguy]

That may be the simple and quick answer, but IMO a better one is for sentinel to have a new command which looks something like:

SENTINEL REMOVESLAVE <name>

This command would remove the given slave from being monitored, causing sentinel to forget about it. Maybe SENTINEL REMOVE <name> which currently removes a master could also be used to remove a slave, I've not explored that code.

However, the ability to tell sentinel "forget this slave" is quite useful. Currently as I understand it Sentinel will continue checking for a known slave forever. In an environment where you scale up reads by adding more slaves, then turning them down you wind up with a which either leaks ports or those slaves are forever belonging to the master they connected to.

Since this is not a command sentinel would call on it's own it would preserve the current functionality while handling the case of needing sentinel to stop trying to manage replication for a given IP:port.

The other way to do it is to fully remove the master from the sentinel constellation then re-add it. That seems a bit drastic and more risky than having a command to remove a slave.

[Mathew Kamkar]

Not sure how recent this is, but from the documentation: "send a SENTINEL RESET mastername command to all the Sentinels: they'll refresh the list of slaves within the next 10 seconds"

[Bill Anderson]

Matthew, the reset command has side effects and produces a period of time where sentinel can not perform a failover, followed by one which can produce split brain, then finally a normal state. 

Salvatore has said (as of the deeper day) that a command to remove a slave will be forthcoming as reset's effects are indeed much larger than are needed. 

You received this message because you are subscribed to a topic in the Google Groups "Redis DB" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/redis-db/e84S3-gVcFI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to redis-db+u...@googlegroups.com.

[anand kumar]

Hi,

 You can use SENTINEL reset <pattern> to reset your sentinel conf. Here pattern refers to redis cluster name which you configured in sentinel conf.

[Sahil Maniar]

try something like this ->

$ redis-cli -p 6380 slaveof no one; redis-cli -p 26379 SENTINEL RESET mymaster; redis-cli -p 26380 SENTINEL RESET mymaster; redis-cli -p 26381 SENTINEL RESET mymaster;