I have a Redis cluster configuration with a master and 2 slaves. I want to enable AOF (fsync:always) on the master for full durability, while RDB in both the slaves. My question is, in case the master fails, and one of the slaves is chosen as the new master; will the old master config be also copied to the new master. And, when the old master restarts as the new slave, will the slave config be copied to the new slave by the redis sentinel automatically?
What you have isn't a Redus cluster, as cluster is a different setup. Pointedly Redis Cluster and Sentinel do not go together.
That said, no, Sentinel does not "copy configuration" it simply elects a new master. A Sentinel constellation elects a new master and issues a slave of Command on it to make it the master, then points any other slaves to the newly minted master. You will either need to write something which picks up the change and reconfigures the new master or keep those configuration items the same.
Related
In a Redis HA setup, with 1 master and 5 replicas:
Let's suppose the master goes down. Then the Sentinels would elect a replica as the next master.
What happens when the original master is restarted with its config? Would it be joining as a master or as a replica? I suppose, since it is not configured as a replica, so it should not be running as a replica.
When the original master is down and a new master is elected. The original master will be added as a virtual replica of the new master. When it recovers, original master will be set to be a replica of the new master automatically.
Master would join as a replica.
...The master will then demote itself to a replica...
https://redis.io/commands/failover
I found that Sentinel is mainly used for promoting slave to master automatically when master failed.
I also found that redis-4.0.11's cluster mode seemly also have this function itself.
So when I use redis-4.0.11's in cluster mode, do I need a Sentinel ?
NO, you don't need sentinels in cluster mode.
When a master is down, the cluster will promote one of its slaves to be the new master automatically.
We have two datacenters, each with two redis instances. Generally they are replicated as chain.
NY1 (Master) --> NY2 (Slave) --> CO1 (Slave) --> CO2 (Slave)
NY is New York and CO is Colorado, our backup datacenter. In order to save bandwidth over the WAN, we don't want CO1 and CO2 connected to NY1. Rather we want a chain configuration, where there is only one slave directly to the master, and the others are all "slaves of slaves".
Can this sort of replication layout be maintained using Sentinel? Or do all slaves have to be a slave of the master, and not a slave of a slave?
Currently this type of setup isn't possible with Sentinel because Sentinel rewrites the configurations of all monitored Redis systems.
For example, if you set up a system as you described and have sentinel monitoring all of the hosts, if the master goes down and forces a failover, each of the Redis hosts will be re-configured. One of the replicas (any of them) will become the new master, and the others will become replicas of the new master. When the old master comes back online, it will be re-configured to be a replica of the new master.
However, in general you can get Redis to work the way you want. You can have as many replicas of a replica as you need by setting the replicaof config value to a replica.
Personally, I would still use Sentinel to monitor the master and the "prime" replicas (those that replicate from the master itself). This could result in one of the prime replicas becoming a new master, so I would enable the notification option. This tells sentinel to call a script whenever a failover happens. In that script you can send an email, hit a Slack webhook, or whatever else you want to do with it. When I get it, I'd manually reconfigure the hosts back into the format I want, but with the new master. It'd be a pain to do it this way but I'd still get automatic failover of the master and prime replicas so my apps will continue working.
Hello stack community,
I have a question about Redis sentinel for a specific problem case. I use AWS with Multi AZ to create a sensu cluster.
On eu-central-1a I have a sensu+redis(M), a RBMQ+Sentinel and 2 others Sentinels. Same on eu-central-1b but the redis is my slave on this AZ.
What happen if there is a problem and eu-central-1a can not communicate with eu-central-1b ? What I think is that Sentinel on eu-central-1b should promote my redis slave to master, because he can not contact my redis master. So I should have 2 redis masters running together on 2 different AZ.
But when the link is retrieved between AZ, I will still have 2 masters, with 2 different datas. What will happen in this case ? One master will become a slave and data will be replicated without loss ? Do we need to restart a master and he will be a slave ?
Sentinel detects changes to the master for example
If the master goes down and is unreachable a new slave is elected. This is based on the quorum where multiple sentinels agree that the master has gone down. The failover then occurs.
Once the sentinel detects the master come back online it is then a slave I believe thus the new master continues I believe. You will loose data in the switchover from master to new master that in inevitable.
If you loose connection then yes sentinel wont work correctly as it relies on multiple sentinels to agree the master redis is down. You shouldn't use sentinel in a 2 sentinel system.
Basic solution would be for you to put a extra sentinel on another server maybe the client/application server that isn't running redis/sentinel this way you can make use of the quorum and sentinels agreeing the master is down.
We have a redis cluster with a master and a slave managed by three sentinel processes, and an additional remote slave, hosted in a different datacenter, for transparent failover and data preservation in the case that something bad happens to the master and slave machines.
It may happen that a transient error takes down the master redis process only, and in this situation we would like to see the slave process promoted to master, and the remote slave reslaved to it. However, it seems that sentinel could just as easily promote the remote slave to master, and we have not found any way to prevent this.
Is there any way to mark a particular slave machine as unpromotable, so that sentinel will not try to make it the master in the event of a failover?
Yes. In the slave's config file set the slave-priority setting to zero (the number not the word).