Interface RedisSentinelOptions<M, F, S, RESP, TYPE_MAPPING>

Client Side Caching configuration for the pool.

Enables Redis Servers and Clients to work together to cache results from commands sent to a server. The server will notify the client when cached results are no longer valid. In pooled mode, the cache is shared across all clients in the pool.

Note: Client Side Caching is only supported with RESP3.

Example: Anonymous cache configuration

const client = createSentinel({
  clientSideCache: {
    ttl: 0,
    maxEntries: 0,
    evictPolicy: "LRU"
  },
  minimum: 5
});
Copy

Example: Using a controllable cache

const cache = new BasicPooledClientSideCache({
  ttl: 0,
  maxEntries: 0,
  evictPolicy: "LRU"
});
const client = createSentinel({
  clientSideCache: cache,
  minimum: 5
});
Copy

The number of clients connected to the master node

The maximum number of times a command will retry due to topology changes.

The sentinel identifier for a particular database cluster

Mapping between the addresses returned by sentinel and the addresses the client should connect to Useful when the sentinel nodes are running on another network

The configuration values for every node in the cluster. Use this for example when specifying an ACL user to connect with

When true, error events from client instances inside the sentinel will be propagated to the sentinel instance. This allows handling all client errors through a single error handler on the sentinel instance.

Default: false

The number of clients connected to each replica node. When greater than 0, the client will distribute the load by executing read-only commands (such as GET, GEOSEARCH, etc.) across all the cluster nodes.

When true, one client will be reserved for the sentinel object. When false, the sentinel object will wait for the first available client from the pool.

Interval in milliseconds to periodically scan for changes in the sentinel topology. The client will query the sentinel for changes at this interval.

Default: 10000 (10 seconds)

The configuration values for every sentinel in the cluster. Use this for example when specifying an ACL user to connect with

An array of root nodes that are part of the sentinel cluster, which will be used to get the topology. Each element in the array is a client configuration object. There is no need to specify every node in the cluster: 3 should be enough to reliably connect and obtain the sentinel configuration from the server