Nuxeo instances should be configured with a Redis server (in addition to the regular SQL database) in the following cases:
- When it's important that asynchronous jobs not yet executed be kept across server restarts.
- In cluster mode to allow:
- Execution of some asynchronous jobs on dedicated nodes (for instance image conversion or full-text extraction).
- A distributed Transient Store, required for Batch Upload and Asynchronous Conversion Works.
- Relying on the
RedisCacheas a distributed implementation of the Nuxeo Drive synchronization roots cache.
- Efficient repository low level cache invalidations (VCS row cache invalidation)
For a robust production instance, the first point is always necessary, which means that Redis should always be used.
The Nuxeo Platform supports the following Redis versions: 2.8.x, 3.0.x, 3.2.x and 4.0.x.
The following Redis configuration points should be checked:
maxmemory-policyshould be set to
noevictionwhich is the default setting of Redis
- The server memory should be enough to hold the Redis database (the size depends on the usage: transient store, cache, the backlog of asynchronous jobs ...).
- Redis persistence should be configured appropriately for the level of service required. In particular the RDB files should be used as backups and periodically saved offsite.
- Redis master-slave replication should be set up, for robustness (fast disaster recovery). Note that Nuxeo Platform does not yet know how to use the slaves for read-only operation.
To make the Nuxeo Platform use Redis, you must activate the following in
nuxeo.redis.host must be the hostname or IP address of your master Redis server. All the Nuxeo instances in a Nuxeo cluster must of course point to the same Redis server.
Also available are (with defaults):
nuxeo.redis.port=6379 nuxeo.redis.prefix=nuxeo: nuxeo.redis.password= nuxeo.redis.database=0 nuxeo.redis.timeout=2000 nuxeo.redis.maxTotal=16 nuxeo.redis.maxIdle=8
nuxeo.redis.port is self-explanatory, 6379 is the value for a default Redis installation.
nuxeo.redis.prefix is the prefix used for all Nuxeo keys stored and read in Redis. This allows you to use a single Redis server between several Nuxeo cluster installations by having a different prefix for each cluster, but this is not really recommended. All keys used for Work queue management have
work: added after this prefix. Those related to caching use
cache: after this prefix. For locking,
lock: followed by the repository name is used.
nuxeo.redis.timeout are standard Redis parameters, although rarely used.
nuxeo.redis.enabled=true then the following is automatically activated as well:
(As of Nuxeo Platform 5.8, work queuing is the only use of Redis in the standard Nuxeo modules, so it makes sense to activate both together.)
nuxeo.redis.maxTotal sets the maximum size of the Redis connections pool (available since HF-05).
nuxeo.redis.maxIdle sets the maximum number of Redis idle connections in the pool (available since HF-05).
If needed, you may configure nuxeo for resolving the redis server through sentinels.
nuxeo.redis.ha.enabled=true nuxeo.redis.ha.master=mymaster nuxeo.redis.ha.hosts=sentinel1,sentinel2,.... nuxeo.redis.ha.port=26379
Nuxeo will ask sentinel hosts in the declaring order at port 26379 for the server mymaster.
The Redis data are transient but should not be flushed while Nuxeo is running, in some case it needs to be reset:
- After a normal Nuxeo cluster shutdown when there are no async job running, the flush is not necessary but possible.
- When performing testing and killing abruptly Nuxeo process.
- After a crash when some inconsistencies are visible in the work manager, like worker being marked as running forever.
Once the Nuxeo instance or cluster is stopped you can drop the Redis data using the
redis-cli command line and send a
flushdb commmand, Nuxeo is using the
db 0 per default.