Shared Instances

When running more than one WordPress installation on the same Redis instance, it’s highly recommended to use a separate Redis database for each site. If several sites must share the same database, use a unique prefix for each site.

  1. Using Databases
  2. Using Prefixes
  3. Size Display
  4. Data Isolation

Using Databases

For the best performance, it’s recommended to use a different database index 0-15 for each WordPress installation, by using the database configuration option.

By default, Redis has 16 databases. This can be increased to in your redis.conf without any performance impacts.

define('WP_REDIS_CONFIG', [
    // ...
    'database' => 0,
]);

Using Prefixes

When only a single database is available (Redis Cluster), each site much have a unique prefix to avoid data collisions. The downside of using a prefix over different databases is that cache flushes are global. If site A flushes the object cache, then site B and C will also be flushed.

define('WP_REDIS_CONFIG', [
    'prefix' => 'mysitename',
]);

Prefixes must be 32 characters or less. For readability avoid special characters and use short, simple strings (apple, apple-jobs) not hashes.

Size Display

By default, Object Cache Pro displays the Redis database size in various places. For technical reasons, this “Redis Memory” number includes all databases, not just the one set using the database configuration option. This can be misleading for end-users, especially after clearing the cache and seeing the “Redis Memory” not drop to (near) zero.

If the instance is shared between multiple sites or users, this confusion can be avoided by using the shared configuration options to display object/key counts, instead of the database bytes.

Data Isolation

ACLs can be used to isolate customers on the same caching server:

ACL SETUSER picard on >secret +@all -@dangerous -select +select|4 +flushdb +keys +info +restore +role

This command will:

  • Create the user picard with the password secret
  • Grant access to @all commands, except @dangerous
  • Limit SELECT access to database 4
  • Grant access to some additional commands like FLUSHDB and INFO

Database 0 is always accessible to all users and cannot be restricted. If shared access in 0 is a concern, a prefix restriction can be used: ~enterprise:*