What happens when data-in-index settings are heterogenous between namespaces


#1

FAQ: What happens when data-in-index settings are heterogenous between namespaces which have data-in-index set to true?

Background

A cluster may contain many namespaces. The data-in-memory and data-in-index settings are specified in the namespace context. Namespaces where data-in-index is set to true are a specific case where warm start is possible. What happens when a node is started and these settings are heterogenous between namespaces? An example is shown below:

namespace test {
replication-factor 2

memory-size 80G

default-ttl 30d

data-in-index true

single-bin true

storage-engine ssd {
file /var/data/aerospike.data
filesize 100G

data-in-memory true

}
}

namespace test-groups {
replication-factor 2
memory-size 40G
default-ttl 30d

data-in-index false

single-bin true


storage-engine ssd {
file /var/data/aerospike-groups.data
filesize 150G

data-in-memory true


}

Answer

The first namespace, where data-in-index is true will be able to warm start but we will still have to wait for the second namespace, where data-in-memory is true but data-in-index is false to cold start.

Notes

Until the message shown below is displayed the main Aerospike server port is not open.

service ready: soon there will be cake!

Until the main server port is open clients cannot connect to the cluster to retrieve the partition map. Without the partition map they are not able to do operations on records.

Warm starting as many namespaces as possible is still worthwhile as it reduces the overall time between the startup command being issued and the ‘Cake’ message.