I'm researching about Redis Architecture. and I don't understand some point about it. please, you explain for me.
follow some document says: "Client will only write data to Master Instance and read-only from Slave instances.". Is it right? if true, in case, Slave is failed, how will read data redis?
About process start a Redis instance, how happened it?
Thanks,
Use Redis sentinel to monitor several redis instances. When the master fails, Sentinels will elect a new master.
Related
I have a Redis cluster of 3 master nodes and each master has corresponding slave nodes. I would like to acquire a lock on the cluster to perform some write operations and then release the lock.
From what I've read is - To connect to a cluster we generally connect to one node in the cluster and perform all operations on that node which in-turn handles re-directing to other nodes in the cluster.
Is it possible to acquire lock on a Redis cluster? [P.S I am using Redisson client]
From the examples in Redisson client under Multilock and redlock (https://github.com/redisson/redisson/wiki/8.-Distributed-locks-and-synchronizers), they are acquiring a lock on individual nodes.
How does Multi lock or Red lock work on a cluster?
How and what kind of lock do I use if I have a Redis cluster?
Which library (Jedis/Redisson) do I use?
Jedis also seems to have support for locking on the cluster (https://github.com/kaidul/jedis-lock).
P.S: I've read extensively on this, but I've not been able to find clear answers on locking on a cluster. Would really appreciate some help.
I found a solution to my question above.
As far as we are using the same key to acquire a lock across all client nodes, all the attempts to acquire the lock will go to the same node on the Redis cluster. So you can just use simple Rlock from Redisson.
See comments to this question:
https://github.com/leandromoreira/redlock-rb/issues/63
I am trying to understand if the Redis replication (described here) relates to the Redis Sentinel (described here) or are totally different approaches to data replication.
You use them both together. If you have a master and a couple of slaves, replication makes sure that data between all three remains consistent, but sentinel will handle promoting a slave to a master if the master dies, redirecting new requests to the new master, and notifying someone about what has happened.
When running a single instance redis, I can use "slave of" to create a (or as many I like) readonly replica of this one redis node.
When using redis cluster, I split my Data into Partitons (Masters) and can create a slave for each partition.
Is it possible to treat this cluster as a single instance and connect a "slave of" Slave to this cluster which will hold a replica of all Data in the cluster and not just the partition of the connected node?
If not possible with redis cluster, is this might a working solution when using sentinel?
Our current Problem:
We are using the "slave of" feature together with keepalived to failover our redis instance on an outage of the master.
But we have lots of "slave of" slaves connected to the virtual IP of the failover setup, to deliver cached data.
Now everytime the system fails over (for maintenance reasons e.g.) all connected slaves have a timout for up to 30 seconds, when they have to resync their data with the new master.
We allready played with all possible redis config parameters but can't get this syncing time to be shorter (e.g. by relying on the replication-backlog, which isn't available on the new master after the failover).
Anyone any ideas?
a very good doc here : http://redis.io/presentation/Redis_Cluster.pdf and here http://fr.slideshare.net/NoSQLmatters/no-sql-matters-bcn-2014 (slide #9) or better https://www.javacodegeeks.com/2015/09/redis-clustering.html
If you want "slave" in Redis cluster mode, you need use replication of all nodes.
Regards,
Well, I just read this article:
https://seanmcgary.com/posts/how-to-build-a-fault-tolerant-redis-cluster-with-sentinel
The author used a single master with Redis Cluster, with 2 slaves per master, instead of one, and he let Redis Sentinel take care of the election of a slave to a master when the master is down.
You could play with this setup to see if the election of Master occurs quickly. While it's happening, clients would be served by a slave and should experience no downtime.
I have a redis master-slave setup and the configuration of the slave is set to slave_read_only:1, but when I enter a PUBLISH command on the slave node it does not fail. I would expect an error, but it just takes the command and nothing else happens. The message is not propagated to the master either.
The question is, why is that? Did I mis-configure redis? Is that a feature? To what purpose? Or is it just a bug?
The problem arises in a setup where automatic failover occurs. A master may become a slave and clients of that slave may publish messages without realizing that it is no master any more. Do I have to check before each message is sent if the redis node is still master?
I use redis 3.0.5
You didn't misconfigure - this is the defined behavior as PUBLISH isn't considered a write command.
Also note, that when replicating published events are replicated from master to slaves (downstream, as usual), so if you're publishing to a slave only clients connected to it or to its slaves and subscribed to the relevant channel will get the message.
Assuming I have a Master-Slave deployment of Redis (1 master, 1 slave) and a client (webapp) that will manage Publish-Subscribe.
Can I Publish messages to the slave and will they be "seen" by the master?
Or should I use only the Master for Publish and the Slave for Subscribe commands?
I've been looking around but couldn't find the answer. Anyone knows?
EDIT: As #jameshfisher pointed out, the link below is regarding Redis Cluster. The comment from #lionello seems to be the correct answer:
Publishing to a slave will not propagate to the master, only the other way around.
The answer is on the cluster-spec docs:
Publish/Subscribe
In a Redis Cluster clients can subscribe to every node, and can also publish to every other node. The cluster will make sure that published messages are forwarded as needed.
The current implementation will simply broadcast each published message to all other nodes, but at some point this will be optimized either using Bloom filters or other algorithms.
For the typical data you store in Redis, you should only write to the master.
From http://redis.io/topics/replication:
...writes [to slaves] will be discarded if the slave and the master will [sic] resynchronize, or if the slave is restarted...
In fact, starting from v2.6, you can put slaves in slave-read-only mode which would prevent the mistake of writing data to a slave.
The documentation does go on to mention a potential use case for writing data to slaves:
...often there is ephemeral data that is unimportant that can be stored
into slaves. For instance clients may take information about
reachability of master in the slave instance to coordinate a fail over
strategy.