Issue: redis/redis#12097
PR: redis/redis#12192
In many scenarios, we need to perform the action of switching. Take a rolling version upgrade as an example, suppose there are two nodes A and B, where A is the master and B is a replica of A. Under normal circumstances, users only access the master node A. Then, during a version upgrade, users would first upgrade the version of the replica node B, then switch to make B the master and turn A into B's replica. Simultaneously, user access also needs to switch from node A to node B, followed by an upgrade of node A to complete the entire version upgrade process:
However, during this process, the switch of user access is not entirely smooth. In fact, there are different reactions under cluster mode and standalone mode:
- In cluster mode, after the switch, when the replica is accessed, Redis will return
-MOVED slot ip:port. In cluster mode, this is a routine result. The client will not treat it as an error returned to the user. Instead, the client will automatically redirect to the new master node B, as indicated by the ip:port in the result, thus achieving a smooth switch.
- In standalone mode, after the switch, accessing the replica will return the error
-READONLY You can't write against a read only replica. The client will pass this error to the user, and a smooth switch cannot be achieved.
As we can see, the switching experience in cluster mode is clearly superior to that of standalone mode. Therefore, to improve the switching process in standalone mode, we can utilize the MOVED redirect mechanism. The first step would require the valkey server to use MOVED to replace READONLY in standalone mode, and then support for handling the MOVED return value needs to be implemented in the client ecosystem.
The latest discussion is we want to introduce a new reply REDIRECT, so it would not breaking anything to cluster.
More details, the slot returned by the replica in the MOVE can be -1, and this can also be applied to cluster mode. It serves to clearly inform the client that it has accessed a replica and should be redirected to the master, rather than having accessed the wrong shard requiring redirection.
Issue: redis/redis#12097
PR: redis/redis#12192
In many scenarios, we need to perform the action of switching. Take a rolling version upgrade as an example, suppose there are two nodes A and B, where A is the master and B is a replica of A. Under normal circumstances, users only access the master node A. Then, during a version upgrade, users would first upgrade the version of the replica node B, then switch to make B the master and turn A into B's replica. Simultaneously, user access also needs to switch from node A to node B, followed by an upgrade of node A to complete the entire version upgrade process:
However, during this process, the switch of user access is not entirely smooth. In fact, there are different reactions under cluster mode and standalone mode:
-MOVED slot ip:port. In cluster mode, this is a routine result. The client will not treat it as an error returned to the user. Instead, the client will automatically redirect to the new master node B, as indicated by theip:portin the result, thus achieving a smooth switch.-READONLY You can't write against a read only replica.The client will pass this error to the user, and a smooth switch cannot be achieved.As we can see, the switching experience in cluster mode is clearly superior to that of standalone mode. Therefore, to improve the switching process in standalone mode, we can utilize the
MOVEDredirect mechanism. The first step would require the valkey server to useMOVEDto replaceREADONLYin standalone mode, and then support for handling theMOVEDreturn value needs to be implemented in the client ecosystem.The latest discussion is we want to introduce a new reply
REDIRECT, so it would not breaking anything to cluster.More details, the slot returned by the replica in theMOVEcan be-1, and this can also be applied to cluster mode. It serves to clearly inform the client that it has accessed a replica and should be redirected to the master, rather than having accessed the wrong shard requiring redirection.