-
Notifications
You must be signed in to change notification settings - Fork 10.5k
Description
Currently, the caching Redis plugin uses a simple ConnectionMultiplexer.ConnectAsync call with the given configuration. Unfortunately, this does not combine well with clusters with a sentinel.
- The current dependent version of
StackExchange.Redisrequires two steps for connecting to a sentinel cluster: first to the sentinel, then to the appropriate master. This scenario cannot be implemented in the current API. - The latest version of
StackExchange.Redis(2.1.58) no longer requires two steps for connecting to a sentinel cluster (Sentinel improvements StackExchange/StackExchange.Redis#1431): when using a normal Connect-call, the code will try and detect whether you connected to a sentinel and then automatically return a normal connection to the current master. However, once the master fails and another master is elected by the sentinels, this connection object is no longer valid and the caching breaks. There is currently no way to re-instantiate the connection easily.
My current workaround is using the new library version, implementing a Redis caching HealthCheck, and simply letting all application containers fail and be restarted by the orchestrator to connect to the new Redis master. This is, of course, not ideal.
It would be very much appreciated if support for sentinels can be incorporated into the library directly. For example, in the RedisCacheOptions add a bool option indicating the use of sentinel, and add code to retrieve the correct master on the fly; and retry this when the connection to the current master fails.