As I thought about implementing failover, I realized it would be useful if the read-only flag were independent of the server's slave status.
When orchestrating failover (to upgrade the master's version of redis, for example), the following steps would be required: 1. Signal to all clients that a failover is occurring (possibly in zookeeper or whatever means you have available) 2. Mark the master as read-only 3. Wait for the new target master to show it has replicated all the commands from the old master 4. Set the new master to slave of none 5. Set the old master to a slave of the new master 6. Turn off read-only on the new master 7. Signal to all clients what the new master's IP and port is
Without being able to mark the old master as read-only, there is no way to ensure that commands were not lost during the failover process.
Comment From: kenperkins
We've been debating exactly how to mitigate these issues for Clipboard as well.
Given that you can write to a slave, could you not do (with a minimum of three redis machines):
Machines: A (master), B & C (Slave of A)
a) Make C slaveof B b) signal clients to use B as master c) Make B slaveof no one d) Make A slaveof B
I'm trying to think outside the box a bit here, maybe I'm missing something.
Comment From: eric
I've implemented the readonly flag in pull request #499.
Comment From: hpatro
Co-ordinated failover has been implemented for both standalone and cluster-enabled setup. It pauses write command on the primary and does the orchestration further which seems to be the request here.
https://redis.io/commands/failover/ https://redis.io/commands/cluster-failover/