Are CHANNELS re-created after MASTER-SLAVE failover

[Srini B]

We have created few CHANNELS in MASTER for PUB-SUB and it works as expected. But, when a failover happens these CHANNELS are not getting created once the SLAVE is promoted as a MASTER.

Is there any option to get this working automatically ? Currently, as a workaround we re-create it programmatically after a failover by storing the created CHANNELS in our Database.

We use REDIS v2.8.19 with JEDIS. Are we missing anything or this is the standard behavior ?

[Jan-Erik Rediger]

What do you mean by "channels created"?
Pubsub channels only exist if someone is subscribed.
Obviously in the case of a master going offline there's no way for Redis
to reconnect clients and subscribe them again.
It's the task of your application to recognize a failover and reconnect
to the new nodes and resubcribe them.
Sentinel can inform you about those failovers so you can reconfigure
your clients.

> --
> You received this message because you are subscribed to the Google Groups "Redis DB" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to redis-db+u...@googlegroups.com.
> To post to this group, send email to redi...@googlegroups.com.
> Visit this group at https://groups.google.com/group/redis-db.
> For more options, visit https://groups.google.com/d/optout.

[Greg Andrews]

Please also describe the mechanism you use for failover to a slave when the master fails.  Do you use Sentinel for this?  Is this a Redis Cluster?  Do you have your own custom scripts/commands to perform the failover?

[The Real Bill]

What you are witnessing is the correct and standard because. It is the responsibility of the clients, be they publisher or subscriber, to create the "channels" by issuing the publish or subscribe on a failover. The server doesn't actually know who needs at the level you would need for it to happen without this.

This works just fine given that the client has to reconnect to a different server anyway. However I would suggest depending on how Jedis handles it you have the subscribers attempt to reconnect on a shorter interval than the master. This will help decrease the chance of lost messages should the publisher publish a message to the new master before a subscriber does.

I've been doing some client testing in the specific area and can confirm that if the client handles the reconnect properly and the publisher(s) connect after the subscribers it works just fine. At least with the libraries I've tested so far. Given I don't know Java I can't comment on whether Jedis handles it properly.

If it is absolutely critical that no messages are lost you would need to either implement some form of quorum to know that all needed subscribers are reconnected before resuming publishing, or use something akin to a queue rather than pub sub. Whether that is feasible will depend on your specific requirements and environment. Redis' pub sub makes no persistence or delivery guarantees at all. It does however know how many clients received a message. With that information it is possible to implement retry on your own in the client side code if the recipient count isn't where you need it to be (such as 0 for example).

Cheers,
Bill

[The Real Bill]

Given it is 2.8 I'm pretty sure it isn't Redis Cluster. ;)

As such whetherit is sentinel, manual, or with a proxy in front the client has to detect the failover (via reconnect at the minimum) and re-establish the pub sub setup.

Cheers,
Bill