ghost
commented
3 years ago We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.
Currently, the caching Redis plugin uses a simple
ConnectionMultiplexer.ConnectAsynccall with the given configuration. Unfortunately, this does not combine well with clusters with a sentinel.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.StackExchange.Redis(2.1.58) no longer requires two steps for connecting to a sentinel cluster (https://github.com/StackExchange/StackExchange.Redis/pull/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
RedisCacheOptionsadd 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.