I would like to make a query (multiple calls) that requires snapshot isolation (No updates). Is there a way to pause a slave from updating itself from master temporarily so that I can run the query?
You can use the SLAVEOF NO ONE command to turn off the replication. When you're done with the snapshot, use the SLAVEOF master-host master-port to re-sync from the master.
Related
I'm currently exploring Redis cluster. I've started 6 instances on 3 physical servers(3 master and 3 slaves) with persistence enabled.
I've noticed that when I kill one of the master instances then it's slave is promoted to master after some time. However, it remains as master even when I start the killed instance.
Since, Redis does asynchronous replication, therefore, I was thinking of a scenario where the master, immediately after flushing the data is killed i.e. it wasn't able to replicate that data.
Will this data get replicated to the new master(initially slave), once
the instance comes back up?
NO. If the master haven't replicate data to slave, the data will be lost. When the old master recovers, it will be become a slave of some other node based on some rules. Then the old master will replicate data from its new master.
the redis.conf says:
1) Disk-backed: The Redis master creates a new process that writes the RDB
file on disk. Later the file is transferred by the parent
process to the slaves incrementally
I just dont know what does "transferred by the parent process to the slaves" mean?
thank you
It is simple. First read the RDB file into a buffer, and use socket.write to send this to salve's port which is listenning this.
The implemention is more complex than what I said. But this is what redis do. You can refer the replication.c in redis/src for more details.
EDITED:
Yes, the disk-less mechanism just use the child process directly sends the RDB over the wire to slaves, without using the disk as intermediate storage.
Actually, if you use disk to save the RDB and redis master can serve many slaves at the same time without queuing. Once the disk-less replication serve on slave, and if another slave comes and want do a full sync, it need to be queued to wait for the first slave to finish. So there are another settings repl-diskless-sync-delay to wait more slave to do this parallel.
And these two method only occur after something wrong happens. In the normal case, the redis master and salve through a well connected wire to replicate the redis command the slave to keep the same between the master and slave. And if the wire is break or the slave fall down, then need do a partial resync action to obtain the part slave missed. If the psync is not possible to achieve, it will try do full resync. The full resync is what we talked about.
This is how a full synchronization works in more details:
The master starts a background saving process in order to produce an RDB file. At the same time it starts to buffer all new write commands received from the clients. When the background saving is complete, the master transfers the database file to the slave, which saves it on disk, and then loads it into memory. The master will then send all buffered commands to the slave. This is done as a stream of commands and is in the same format of the Redis protocol itself.
And the disk-less replication is just a new feature which supports the full-resync in that case to deal with the slow disk stress. More about it refer to https://redis.io/topics/replication. such as how do psync and why psync will fail, you can find answer from this article.
When working with a single redis instance I can be sure that commands inside MULTI will be processed as a single atomic operation.
What happens when redis operates in cluster mode?
Can I be sure slaves won't get intermediate result of MULTI but only the whole/none of commands that were send as a MULTI(transaction)?
added: all commands inside MULTI operating on the same slot and keys are tagged with {tagName}
Thanks!
Redis' replication between master and slave(s) is designed to honor MULTI's assurances, so yeah, you can be sure. Put differently, the replication stream that the slave gets is a built out of the write operations that the master performs. These are sent in order, and since MULTI guarantees atomicity on the master, it follows that the same applies to the slaves.
I want to be able to access a very recent copy of my master Redis server keys. It doesn't have to be completely up to date as I will be polling the read only copy but I don't want the transactions and Lua scripts I run on the master instance to block on the read only instance as I SCAN through the keys on my read only instance.
Can anyone confirm/deny this behaviour?
It won't block the slaves from anything, but while the master is busy processing your logic replication will be stopped. Once the logic ends (possibly generating writes), replication will resume with the previous buffered contents and the new ones (if any).
I have commented the "save" commands in both my master and slave as I want to do only in memory caching and not persist to the file. This works fine but as soon as the Master goes down and before Slave can be promoted to master ( It actually freezes for a min ) it starts flushing the data. How can I prevent the slave from flushing the data.
Thanks
zafer
Actually, the slave does not flush the data when the master goes down.
It starts a SYNC (flushing the data before) with the master, when it has lost the connection with the master, and has established the connection again.
IMO, the problem is the master restarts immediately, so the slave can reconnect before it has been promoted to master.
You should delay the restart of the master until the slave have been promoted. Depending on how the HA is automated, it may not be very convenient. A simple (but not very reliable) solution is to just put a delay in the start script of the Redis instance. The delay should be calculated so that you are 100% sure the slave will be promoted before it times out. A more complex solution is to try to connect to the slave in the start script of the master, and run the INFO command to check its status, before allowing the start.
See the following discussion for more information:
https://groups.google.com/d/topic/redis-db/wmRSuIgHcEs/discussion