Pub/Sub subscribe to +switch-master events.

[ldm5180]

The master can change even without a disconnect happening to the client. In order to get this change the clients must subscribe to the +switch-master message. This needs to be subscribed before the client connection is established to avoid race conditions.

[jamessharp]

This is great - thanks. I think there's a race condition

• reconnectAllClients calls connection_gone, which in turn emits 'reconnecting' which causes redis-sentinel to request the master/slave/whatever endpoint again and then node_redis sets a timer to attempt a reconnect.
• In the case where the sentinel responds with endpoint details before the retry timer is up then all is fine. node_redis just connects to the new endpoints.
• However I doubt that will happen very often. In the case where the retry timer calls first then node_redis will reconnect back to the old master. Even when the sentinel response comes back we won't do a reconnect so we'll stay connected to the old master.
• The fix is non-trivial because you can't just say 'when we get a response from sentinel check if the endpoints have changed and if they have reconnect'. This is because in the intervening period (when we've reconnected to the old master before the sentinel response has come back) commands could well have been issued to the old master and any writes to the DB will fail.

The solution is probably along these lines:

• In refreshEndpoints initially null route the address (i.e. set client.connectionOption.host = '0.0.0.0')
• Then once resolver returns set the correct address (as today) then call connection_gone again to make sure we do attempt a reconnect.

I'm not sure that setting the null address won't kill node_redis but is worth a try.

[ldm5180]

Yes, there is certainly a race there. I fixed the race with the fix you suggested and tested it using a slow Sentinel. It seems to work fine.

[jamessharp]

Looks good. Thanks!