While executing the info command in redis-cli, all the information related to that server is listed. What is the purpose of "evicted_keys"?
Redis can be configured to automatically purge keys as necessary. If so configured, redis will only use a maximum amount of memory, and if it nears the limit, remove keys per some criteria. See Redis as an LRU cache by antirez.
It can be configured to only remove keys that have an expiry time, or all keys. It can remove keys soon to be expired, last recently used keys, or random keys.
evicted_keys in the info is the number of keys that have been evicted (removed).
Related
Problem:
I want to set a TTL on a key (to avoid it lasting forever) but I do NOT want to have that specific key to be evicted.
When I am setting the TTL I know when it will be safe to expire that cache, but it is NOT safe to expire the cache before this time, and eviction presents the risk of having this cache expire to early.
Context:
I am using Redis to cache an object in multiple languages, if the underlying data changes however I want to remove all associated caches from Redis.
The way I went around and sorted this problem was to create a SET on Redis that contains a reference to the keys in every language. My concern is that if that SET is evicted - I loose the reference to the other keys, and risk having them persist on the cache when they shouldn't.
What I am looking for
A Redis command that looks something like
PLEASE_DO_NOT_EVICT key
while not preventing that key from expiring after the TTL runs out.
Thanks very much for taking your time to reading and answering!
While I could use wildcard matching to find all of the associated keys, this is WAY slower than SMEMBERS, and I am doing this in an environment where every MS counts, as these objects are created and deleted very frequently, so this query happens very often.
Not having a TTL in these objects means they start building up in memory which is undersirable. And they do tend to stop being referenced after a while
Having a no eviction policy seems risky, and I would very much want to
When creating:
SADD 'object:id:group', 'object:id:spanish'
SETEX 'object:id:spanish', 'Este es el object en espaniol', 100
EXPIRE 'object:id:group', 100
When expiring the group because the object changed:
SMEMBERS 'object:id:group'
=> 'object:id:spanish', 'object:id:english'
DELETE 'object:id:spanish', 'object:id:english'
DELETE 'object:id:group'
You can set the maxmemory-policy to its default value of "noeviction". In this mode, no keys are evicted.
How to get all the keys/data stored in "redis" in the last one hour. I searched to found it out, but couldn't find a way. Is there any way to get this.?
Redis does not have a direct way to do this.
Depending on your use case, in increasing order of complexity -
You can manually add newly created keys to a set. The name of the set can include the timestamp. You can then query this set to find keys that have been modified
You can use redis keyspace notification to get notified of keys when they are changed. However, be aware that pub/sub notifications are "fire and forget" - so if your connection drops - you will lose some of the keys that were updated.
You can look at the AOF file and identify keys that have been created / modified. If you are using a cloud provider for redis - they may not provide access to the AOF file. Also, the AOF file doesn't have the timestamp, but the commands are in the order they were processed by redis.
Is there an efficient method to count specific class of keys on a Redis cluster?
Here, 'specific class of keys' means the keys that are used for a common purpose; for example, session keys. They can have a common key name prefix. There can be multiple classes. From now, I will refer the class of keys as simply the keys.
What I want to do is as follows:
Redis cluster must be used.
The keys must be distributed to the nodes of the Redis cluster.
There must be an efficient way to count the number of the keys on all of the nodes of the Redis cluster.
The keys can have TTL - that is, can expire.
The number of the nodes of the Redis cluster can be changed on runtime, and hash slots can be redistributed.
Clients are implemented using Node.js.
I've read the documentation, but could not find a proper solution.
Thanks in advance.
No, basically. That doesn't exist for "classic" (non-cluster), either. To do that without an additional storage mechanism, you would need to use SCAN repeatedly to iterate over the entire keyspace. Fortunately it does at least accept a filter (so you don't need to fetch every key), but is far from efficient - you'd typically only do this periodically as a review feature, not an operational feature. We actually include such a feature in "opserver"'s redis plugin.
When you switch to cluster, you'd need to repeat this but on one of each set of replication verticals. You would typically get that list via the CLUSTER commands, so the dynamic nature of the nodes is moot.
In both classic and cluster, it would be recommended to only do this on a replica - not the master. And again: only as an admin tool, not as a routine part of your system.
Do not use KEYS to do this. Prefer SCAN.
Is there anyway to create a Redis database where keys HAVE TO expire after a certain time? I know I can expire an individual key using the EXPIRE command but since I am expiring every key after a certain time anyways, it would be nice to have this behavior specified in the Redis config file.
No, Redis (up to and including v3.2) does not provide the means for automatically setting the TTL of newly-created keys. You have to set it explicitly for each key you create.
If I have several hashes on Redis, each with keys that expire in 24 hours, if memory runs out while using an eviction policy like allkeys-lru, will Redis remove an entire hash or single keys?
Redis only supports expiration at the key's level. Therefore, once set with a TTL, your key that contains a hashmap will be expired entirely (all child fields will be gone with it). The same goes for the other Redis data types (e.g. Sets and Lists).
If you use Hashes for storing key names that need to expire, simply set the TTL for each such key name individually instead of for the Hash's key.