does it handle nodes master-slave failover? about redisc HOT 6 CLOSED

Many thanks, Martin!

from redisc.

Hello,

It does handle cluster failover, it is a full implementation of the redis cluster spec for a client (https://redis.io/topics/cluster-spec). There is no option to be notified when a failover occurs, AFAIK there is no such option in redis (the only thing I found was this slightly unsatisfying stack overflow answer: https://stackoverflow.com/questions/36449254/how-to-get-notifications-about-failovers-in-redis-cluster-to-the-client-applicat).

Hope this helps,
Martin

from redisc.

I keep set of persistent connections and faced up with case when 2 nodes made failover. So one of connections become connection to r/o slave node. It looks like I need to make separate watchdog goroutine based on ROLE command.

from redisc.

Yeah possibly, this is redis behaviour in play. Is there anything else specific to redisc you'd want to raise or discuss? Otherwise we can close the issue.

from redisc.

I see ReadOnly() method in redisc/conn.go file. if I add new one:
func (c *Conn) IsReadOnly() bool {
c.mu.Lock()
defer c.mu.Unlock()
return c.readOnly
}

• will it answer "true" in this case, when connected node become slave?

from redisc.

No, the ReadOnly() method is used to indicate that a connection to a replica should be preferred, as data will only be read (https://pkg.go.dev/github.com/mna/redisc#Conn.ReadOnly). This results in execution of the READONLY redis command after connection, so that the replica agrees to serve commands (otherwise it would always redirect to the primary node - https://redis.io/commands/readonly).

As you mentioned earlier, the proper way to check if the connected node is a replica is to execute the ROLE command at the place and time when you need that information.

If you want to monitor failover, the idea of running a dedicated connection to each node involved and checking the ROLE at some interval seems like a good option (though I think that would only be for primary-replica failover, not cluster participation). There may be better ways using the CLUSTER ... suite of commands, depending on how accurate you want the reports to be. For example, you could probably use a single connection to a random node to the cluster and call CLUSTER NODES and check the flags for failure stats and primary/replica state (https://redis.io/commands/cluster-nodes).

from redisc.