How do I use configurations
- By default, Aerospike does not set any time-to-live on the records that it writes on the server unless
default-ttlis set on the namespace and relies on the application to maintain or clean-up data as necessary. In the event that you rely on Aerospike’s expirations to maintain the capacity limits on the server, you can set the
default-ttlaccordingly. Note that this is set at the namespace level and is a dynamic configuration (does not require an Aerospike service restart).
max-ttldefines the upper limit to the TTL that can be set on the records. This configuration is used to prevent the server from getting data from rogue clients with TTL higher than expected. This has an upper limit of 10 years (even if this configuration is not set explicitly).
default-ttlcannot be set higher than the
cold-start-evict-ttlis used to define the TTL such that records having TTL below this value will be evicted during a cold-start of Aerospike service. This helps speed up cold-start process in case of evictions during cold restart.
What is the maximum limit of these configurations that can be set on a namespace?
default-ttlcannot be set higher than
max-ttlcannot be set higher than 10 years (for versions 3.8.3 and above).
cold-start-evict-ttldoes not have an upper limit as such, but knowing that the
max-ttlon the server cannot be beyond 10 years, this limit holds true for the
How to change TTL from server and application?
What are the range for the TTL? Why is there -1 and -2?
The TTL are basically positive integers with the value 0 (on the server) referring to non-expirable data.
- From the client API:
- When setting TTL to -1 in the client policy, data will never expire. Internally, the record is stored as 0.
- When setting TTL to 0 in the client policy, the record TTL will use the value specified by
- When setting TTL to -2 in the client policy, the record TTL will not be updated when the record is updated but will use the
default-ttlvalue at record creation. Available for server version 3.10.1 and above.
For details, refer to the Setting TTL for Data Expiration document.
How to determine non-expirable records?
You can use the following asadm command to determine the number of non-expirable records for 3.9+:
show stat like non_expirable_objects
show stat like non-expirable-objects
Alternatively, one can write a UDF to scan records based on the
record.ttl field. It could turn into an intensive operation that may affect a production system’s performance.
The How to Modify TTL using UDF article provides such example.
TTL related WARNINGs
For versions 3.8.3 and above:
WARNING (info): (thr_info.c:2934) max-ttl must be >= default-ttl (current value in seconds)
- If the incoming TTL record is configured more than the configured max-ttl:
WARNING (rw): (write.c:776) write_master: invalid ttl 'value of incoming TTL'
- If the
max-ttlis configured to higher than the global maximum of 10 years:
WARNING (info): (thr_info.c:2930) max-ttl must be non-zero and <= 315360000 seconds
For versions prior to 3.8.3:
The following warnings are seen which point towards an anomaly in the TTL values.
- If the incoming TTL is configured more than the
max-ttl= 8640000 = 100 days), you would see one of these warnings:
WARNING (rw): (thr_rw.c:3226) write_local: incoming ttl 4294938278 too big compared to 8640000 WARNING (rw): (thr_rw.c::3197) record TTL 1459720873 exceeds warning threshold 315360000 - set config value max-ttl to suppress this warning
TTL MAX-TTL DEFAULT-TTL