Before you start: migrate from Aerospike to KiviDB
Before you start. Migrate to KiviDB: Move from Redis, Valkey, ElastiCache, Redis Cloud, Aiven, Aerospike, Hazelcast and more: getting the data out, loading it
Check these on the Aerospike side:
| Check | How | Why |
|---|---|---|
| Edition and version | asadm -e "info network", or the server log's first line | Community Edition has no XDR or Connect, which decides how you catch up during the move. |
| Namespaces and sets, record counts | asadm -e "info set", or asinfo -v "sets/<namespace>" | What you are moving, and the counts to compare afterwards. Counts include replica copies; divide by the replication factor. |
| Whether keys are stored | Scan a few records with aql: SELECT * FROM <ns>.<set> LIMIT 5, and look for the PK column | Without a stored key, a record can be copied but only named by its digest. |
| Bin types in use | The same aql sample, and your code | Lists, maps or nested values point to JSON. HyperLogLog bins have to be rebuilt. |
| Secondary indexes | asinfo -v "sindex-list:" | Each becomes part of an FT.CREATE (or a geo set). |
| UDFs | asinfo -v "udf-list" | Each one needs rewriting. |
| TTL policy | default-ttl and nsup-period in each namespace; how the code passes TTLs | See TTL. |
| Data size | asadm -e "show statistics namespace" (data_used_bytes), or data_used_bytes per set in asinfo -v "sets/<namespace>" | Sizing. |
Sizing. KiviDB keeps everything in memory, including what Aerospike kept on
SSD. Measure rather than estimate: copy one set (or a sample with --set) into
a test KiviDB, then compare used_memory from INFO memory with the number of
keys, and scale. Leave room for growth and for the snapshot that persistence
writes.
Which KiviDB. The loader and the code in this guide use no Lua, so any
build works: the default build, or tls/full when clients connect over TLS.
On KiviDB Cloud, the default settings work. Turn on persistence on a self-hosted
server (--aof) before loading data you cannot reload.