I have configured two slaves and one master using sentinel.
I have turned off persistence on all the servers. Now the sync happens between master and slave using BGSAVE command.
So shall i assume that though i have persistence off redis is still persisting since it created rdb file for syncing data?
I guess you just have to use replication diskless to avoid Redis using BGSAVE. In fact diskless replication use socket instead of the file to send data on their slaves
https://deepsource.io/blog/redis-diskless-replication/
regard,
Related
Based on Redis documentation, a cluster of two Redis nodes (one Master node and one Slave node) can support replication via the slaveof directive.
However, this implies that replication is always performed from Master to Slave.
Assuming we don't use Sentinel, then in case of a failover, the Slave will have the proper data but will still be a Slave node. Thus, as soon as the Master node recovers from failure, data will either be wiped out or be as per the latest snapshot (if RDB/AOF persistence is enabled).
Now, to the question: does Redis support cross replication between Master/Slave nodes? If not, is there a way to replicate (no pun intended) such a functionality without using Sentinel?
Our current Redis setup is a Web application client using Jedis to directly connect using one JedisPool for writes to a single Redis master and a second JedisPool for reads from a single Redis slave. The slave is setup to replicate the master.
We are in the process of moving to using the JedisSentinelPool on the client and introducing Sentinel(s) to handle failover more cleanly. As far as I know, it seems that the JedisSentinelPool only communicates with the currently elected master, so now all writes/reads go to the master. Compared to before when the reads could be distributed to the slave.
Is there any way using JedisSentinelPool to distribute the reads to the slave for load balancing purposes? Or it is necessary to implement this manually with a JedisPool (as before) In which case if the master failed, the JedisSentinelPool would now point to the old slave (new master) and the JedisPool would still dumbly point to the old slave, and effectively the old slave (new master) would now be handling reads AND writes?
Does the Redis Sentinel (or otherwise) have any load balancing (as opposed to failover) capabilities? We currently only have one slave, could adding more slaves be used for load balancing? And if so what are the recommended configurations?
Any advice, real-world experience here would be appreciated.
I write a new JedisSentinelPool , can read from slave with load balancing ,write from master ,it use the redis subscribe the slaves, I use it in my Web application , see code github sentinel-slave-jedis-pool
Redis have 2 persistence options: RDB and AOF. But not sure if it uses them to replicate data from masters to slaves. Should i keep one of them enabled for redis cluster or does it replicate data in some other way?
In documentation i found:
"If you wish, you can disable persistence at all, if you want your data to just exist as long as the server is running."
but not sure if this also true for cluster
Persistence is separate from replication; Redis uses the network for replication. You can disable persistence and still have replication from masters to slaves.
Redis's replication starts upon connection of a slave to the master. But after the inital replication is over, how does the slave continuously stay in sync with the master? I could not find any part of the documentation describing this mechanism. In particular, how can I measure the lag between the master and the slave?
After the initial replication, the master writes changes to internal buffers and sends them to the slave(s). From the replication page:
The master will then send to the slave all buffered commands. This is
done as a stream of commands and is in the same format of the Redis
protocol itself.
You can look at the full replication source code (this points to Redis version 3.0) on GitHub for the nitty-gritty details.
As far as latency is concerned, there is a page dedicated to latency troubleshooting and one dedicated to latency monitoring. These two pages contain a plethora of background information and techniques to troubleshoot/measure Redis latency. A simple place to start is by running redis-cli --latency -h 'host' -p 'port' from slave to master and/or master to slave.
I believe you can find that out by doing issuing INFO replication on the slave and examining the value of slave_repl_offset.
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).