Redis replication and not RO slaves

Question

Good day!
Suppose we have a redis-master and several slaves. The master goal is to store all data while slaves are used for quering data for users. Hovewer quering is a bit complex and some temporary data needs to be stored. And also I want to cache the query result for a couple of minutes.

How should I configure replication to save temporary data and caches?

Answer 1

Redis slaves have optional support to accept writes, however you have to understand a few limitations of writable slaves before to use them, since they have non trivial issues.

1. Keys created on the slaves will not support expires. Actually in recent versions of Redis they appear to work but are actually leaked instead of expired, until the next time you resynchronize the slave with the master from scratch or issue FLUSHALL or alike. There are deep reasons for this issue... it is currently not clear if we'll deprecate writable slaves at all, find a solution, or deny expires for writable slaves.
2. You may want, anyway, to use a different Redis numerical DB (SELECT command) in order to store your intermediate data (you may use MULTI/.../MOVE/EXEC transaction in order to generate your intermediate results in the currently selected DB where data belongs, and MOVE the keys off to some other DB, so it will be clear if keys are accumulating and you can FLUSHDB from time to time).
3. The keys you create on your slave are volatile , they may go away in any moment when the master will resynchronize with the slave. Does not look like an issue for you since if they key is no longer there, you could recompute, but care should be take,
4. If you elect this slave into a master you have additional keys inside.

So there are definitely things to take in mind in this setup, however it is doable in some way. However you may want to consider alternative strategies.

1. Lua scripts on the slave side in order to filter your data inside Lua. Not as fast as Redis C commands often.
2. Precomputation of data directly in the actual data set in order to make your queries possible just using read only commands.
3. MIGRATE in order to migrate interesting keys from a slave to an instance (another master) designed specifically to perform post-computations.

Hard to tell what's the best strategy without in-depth analysis of the actual use case / problem, but I hope this general guidelines help.