RedisSentinelBackend doesn't work with "db" number other than 0

Start at RedisSentinelBackend and reproduce the configuration with sentinels, service_name, and db: 2; compare its connection behavior with the redis-cli Sentinel example. Check how the backend handles the Sentinel node versus the Redis master. Done means a nonzero db stores cache keys successfully through Redis Sentinel without sending SELECT to a Sentinel node.

Hello,

we are trying to setup RedisSentinelBackend with a non-default db parameter to specify the database of the Redis server where the cache keys should be stored.

However when specifying db parameter other than 0, following error is raised by the Redis client:

redis.exceptions.ResponseError: unknown command `SELECT`, with args beginning with: `2`

Here is our configuration in a simple local setup (we use YAML format, however it shouldn't really matter here):

  dogpile_cache:
    regions: short_term,jwt_duration,oauth_access_token_duration,hourly
    backend: dogpile.cache.redis_sentinel
    arguments:
      sentinels:
        - [127.0.0.1, 26379]
      db: 2
      distributed_lock: True
      thread_local_lock: False
      service_name: mymaster

Of course everything works fine when parameter db is removed or set to 0.

I presume what is happening is that Redis client is told to use command SELECT 2 when working with a Sentinel node, while this command is not known by Sentinel.

I can reproduce the issue in redis-cli when connected to a Sentinel node:

127.0.0.1:26379> select 2
(error) ERR unknown command `select`, with args beginning with: `2`, 

This seems to be an issue in RedisSentinelBackend of dogpile.cache, because when using e.g. Celery, we are able to specify the db numbers with Sentinel connection strings and keys are then properly created in the db of our choice.

I was also wondering if there could be some workaround for this issue, e.g. using connection_kwargs parameter? I tried passing the db argument to it, however it did not work.

Any help is greatly appreciated, because in our current setup we can't store the cache keys in db 0 of Redis, which currently blocks us from switching to Redis Sentinel setup.