overwriting default-ttl of Aerospike namespace - aerospike

is there any restriction for client ttl over default-ttl of namespace. for an example ,can we set ttl while writing record to higher then default-ttl of namespace.
or it can have any value irrespective of default-ttl of namespace.

Post server version 4.9, if your namespace is configured to default settings, (default-ttl 0 & nsup-period 0), server will not accept client writes with >0 ttl.
If you want to create/update records with finite ttl (< = 10 years max), set nsup-period to > 0 seconds - enables nsup. Once nsup is enabled, you can insert records with any ttl from the client.
When updating a record which has remaining ttl - say 1 year - from client to ttl = 10 seconds, i.e. trying to set ttl below remaining life - to force expire it out of the system is a bad idea. If you restart the node, there is a 50% chance that the record will be resurrected. So, it is recommended to not set ttl from client below remaining life of the record in the server.
Special client TTL values:
-1 --> make it live-for-ever (unset ttl),
-2 --> update record without changing its current remaining TTL.

Related

What's default TTL in Redis?

I can't find anywhere online what is default TTL in Redis.
I know that I can set TTL for specific SET, but don't know what is default TTL.
Can someone tell me what default time to live is in Redis?
There is no default TTL. By default, keys are set to live forever.
The keys with no expiration time set will not expire.
If you mean TTL command specifically, starting with v2.8, it will return -2 if no EXPIRE value is set.
Edit:
Itamar Haber's comment is true, I recalled false: There is no such setting in redis config for a global TTL. So I deleted the part about that.
Edit2: Also see the link to the official docs about default expiration of keys here: https://redis.io/commands/expire#appendix-redis-expires
I suppose value set to '-1' by default which means forever.
127.0.0.1:6379> set datakey "my-data"
OK
127.0.0.1:6379> TTL datakey
(integer) -1
127.0.0.1:6379>
REDIS Docs says
Starting with Redis 2.8 the return value in case of error changed:
The command returns -2 if the key does not exist.
The command returns -1 if the key exists but has no associated expire.

Number of expiring keys listed by info command on redis slave not consistent with what I see

When I run the info command in redis-cli against a redis 3.2.4 server, it shows me this for expires:
expires=223518
However, when I then run a keys * command and ask for the ttl for each key, and only print out keys with a ttl > 0, I only see a couple hundred.
I thought that the expires is a count of the number of expiring keys but I am not even within an order of magnitude of this number.
Can someone clarify exactly what expires is meant to convey? Does this include both to-be-expired and previously expired but not yet evicted keys?
Update:
Here is how I counted the number of keys expiring:
task count_tmp_keys: :environment do
redis = Redis.new(timeout: 100)
keys = redis.keys '*'
ct_expiring = 0
keys.each do |k|
ttl = redis.ttl(k)
if ttl > 0
ct_expiring += 1
puts "Expiring: #{k}; ttl is #{ttl}; total: #{ct_expiring}"
STDOUT.flush
end
end
puts "Total expiring: #{ct_expiring}"
puts "Done at #{Time.now}"
end
When I ran this script it shows I have a total expiring of 78
When I run info, it says db0:keys=10237963,expires=224098,avg_ttl=0
Because 224098 is so much larger than 78, I am very confused. Is there perhaps a better way for me to obtain a list of all 225k expiring keys?
Also, how is it that my average ttl is 0? Wouldn't you expect it to be nonzero?
UPDATE
I have new information and a simple, 100% repro of this situation locally!
To repro: setup two redis processes locally on your laptop. Make one a slave of the other. On the slave process, set the following:
config set slave-serve-stale-data yes
config set slave-read-only no
Now, connect to the slave (not the master) and run:
set foo 1
expire foo 10
After 10 seconds, you will no longer be able to access foo, but info command will still show that you have 1 key expiring with an average ttl of 0.
Can someone explain this behavior?
expires contains existing keys with TTL which will expire, not including already expired keys.
Example ( with omission of extra information from info command for brevity ):
127.0.0.1:6379> flushall
OK
127.0.0.1:6379> SETEX mykey1 1000 "1"
OK
127.0.0.1:6379> SETEX mykey2 1000 "2"
OK
127.0.0.1:6379> SETEX mykey3 1000 "3"
OK
127.0.0.1:6379> info
# Keyspace
db0:keys=3,expires=3,avg_ttl=992766
127.0.0.1:6379> SETEX mykey4 1 "4"
OK
127.0.0.1:6379> SETEX mykey5 1 "5"
OK
127.0.0.1:6379> info
# Keyspace
db0:keys=3,expires=3,avg_ttl=969898
127.0.0.1:6379> keys *
1) "mykey2"
2) "mykey3"
3) "mykey1"
127.0.0.1:6379>
Given that in your situation you are asking about key expiry on slaves, per https://github.com/antirez/redis/issues/2861:
keys on a slave are not actively expired, and thus the avg_ttl is
never calculated
And per https://groups.google.com/forum/#!topic/redis-db/NFTpdmpOPnc:
avg_ttl is never initialized on a slave and thus it can be what ever
arbitrary value resides in memory at that place.
Thus, it is to be expected that the info command behaves differently on slaves.
The expires just returns the size of keys that will expire not the time.
The source code of 3.2.4
long long keys, vkeys;
keys = dictSize(server.db[j].dict);
vkeys = dictSize(server.db[j].expires);
if (keys || vkeys) {
info = sdscatprintf(info,
"db%d:keys=%lld,expires=%lld,avg_ttl=%lld\r\n",
j, keys, vkeys, server.db[j].avg_ttl);
}
It just calculate the size of server.db[j].expires. (note j is the database index).

Beginner Redis Command

I'm going through the tutorial on redis and came across a command that didn't make sense. From my code below, I'm getting a -2 time-to-live return value for a key that definitely does still exist. Shouldn't my code have returned a -1 for never expiring?
The tutorial says:
Redis can be told that a key should only exist for a certain length of time. This is accomplished with the EXPIRE and TTL commands.
SET resource:lock "Redis Demo"
EXPIRE resource:lock 120
This causes the key resource:lock to be deleted in 120 seconds. You can test how long a key will exist with the TTL command. It returns the number of seconds until it will be deleted.
TTL resource:lock => 113
// after 113s
TTL resource:lock => -2
The -2 for the TTL of the key means that the key does not exist (anymore). A -1 for the TTL of the key means that it will never expire. Note that if you SET a key, its TTL will be reset.
SET resource:lock "Redis Demo 1"
EXPIRE resource:lock 120
TTL resource:lock => 119
SET resource:lock "Redis Demo 2"
TTL resource:lock => -1
This is the code that I typed into the interactive terminal. My assumption is that the 3rd line should've given me back -1, for never expiring. I never set an expiration time so I don't know why I'm getting back -2.
> SET loggedIn "True"
OK
> TTL logggedIn
(integer) -2
> GET loggedIn
"True"
You have a spelling error: you set a key named loggedIn, while trying to get the TTL of logggedIn

AeroSpike created TTL in my records

I'm having hard time understanding the following from AeroSpike documentation:
http://www.aerospike.com/docs/client/python/usage/kvs/record-structure.html
A record also has two metadata values associated with it - the record generation (the number of times it has been modified) and its ttl. A ttl can be set to the numbers of second remaining till it is considered expired, or to 0 (for 'never expire', and the default). Records whose ttl has expired will be garbage collected by the server. Each time the record is written or touched (using touch()) its ttl will reset.
My initial thought was that if namespace policy default ttl is set to 0 then the records will not expire.
My Aerospike namespace configuration is the following :
namespace brand {
replication-factor 2
memory-size 4G
default-ttl 0 # 30 days, use 0 to never expire/evict.
storage-engine memory
# To use file storage backing, comment out the line above and use the
# following lines instead.
set twitter {
set-disable-eviction true
}
storage-engine device {
file /opt/aerospike/data/bar.dat
filesize 16G
data-in-memory true # Store data in memory in addition to file.
}
}
I made a few inserts into the database, then when I retrieved the data I got the following :
{ name: 'test',
twitter: 'test',
domain: 'test.com',
description: 'Your First Round Fund' } { ttl: 4294967295, gen: 2 }
Somehow a ttl appeared on the record and other records have a ttl also. I don't want my records to be deleted from the database. How can I remove the ttl from the records and how can I prevent this from happening in the future?
"asadm -e 'show stat like ttl' Shows the following:
~~~~brand Namespace Statistics~~~~
NODE : 1
cold-start-evict-ttl: 4294967295
default-ttl : 0
max-ttl : 0
~~~~test Namespace Statistics~~~~~
NODE : 1
cold-start-evict-ttl: 4294967295
default-ttl : 2592000
max-ttl : 0
asinfo -v 'hist-dump:ns=brand;hist=ttl' Shows the following
brand:ttl=100,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0;
The node.js get operations meta information is displaying { ttl: 4294967295, gen: 2 }.
Alright! So the TTL unsigned 32 bit integer, you are seeing the maximum value of (2^32 -1) if it were a signed it it would be -1. The max value has special meaning in Aerospike and it means that it lives indefinitely. Aerospike has accepted -1 as indefinite for about a year now and 0 from the client means use server default.
The node.js client is based on our c client which was changed to convert ttl 0 values from the server to 0xFFFFffff or -1. This was mentioned in the c client's 3.0.51 release notes.
Thanks for highlighting this issue, looks like there are some stale docs around this area.

Absolute and Sliding Caching In Redis

I want to implement Absolute and Sliding Caching In Redis. Does anyone have any resource link then it will be helpful
Redis already have many commands for this :
EXPIRE : Set a timeout on key.
EXPIREAT : Same as previous but takes an absolute Unix timestamp (seconds since January 1, 1970).
TTL : Returns the remaining time to live of a key that has a timeout
One important thing you have to know about Expiration on Redis : the timeout value is cleared only when the key is removed or overwritten using SET or GETSET. All others commands (INCR, LPUSH, HMSET, ...) will never change the initial timeout.
Absolute expiration is a native feature of Redis using EXPIRE. To implement a sliding expiration you simply need to reset to timeout value after each command.
A basic way to do this could be
MULTI
GET MYKEY
EXPIRE MYKEY 60
EXEC