Get the data out: migrate from Aerospike to KiviDB
There are three ways, and most moves use the first.
There are three ways, and most moves use the first.
1. Scan with a client (recommended)
A client scan reads every record in a namespace, partition by partition, including its key (if stored), its bins, its generation and its remaining TTL. Aerospike splits each namespace into 4096 partitions, so a scan can be run in parallel, stopped, and resumed by partition. It works on Community and Enterprise Edition, needs no downtime, and is what the loader does.
A scan is not a snapshot: records written while it runs may or may not be included. The cutover runbook closes that gap.
2. From an asbackup file
asbackup writes a namespace to a .asb file: a text format, one record after
another, with list and map bins as base64-encoded MessagePack. The file also
holds the secondary index definitions and UDFs. Aerospike now calls
asbackup and asrestore legacy and recommends absctl backup, which writes
the same format.
asbackup -h 10.0.0.5 -p 3000 -n app -o app.asb
No tool converts .asb into anything KiviDB reads. To move a backup, restore
it into a scratch Aerospike server (Community Edition is enough), then run the
loader against that server:
asrestore -h scratch.internal -p 3000 -i app.asb
python as2kivi.py --aerospike scratch.internal:3000 --namespace app --kividb ...
The restore keeps keys, bins and expiry times. It does not keep generations:
every restored record has generation 1, so --gen-field starts all versions
again. The format is documented by its decoder in
aerospike/backup-go if you want to
write your own reader.
3. Change capture (Enterprise Edition only)
XDR, and the Aerospike Connect outbound connectors built on it (Kafka, JMS, Pulsar and others), stream every write as it happens. They need Enterprise Edition with a feature key that enables them; Community Edition has neither. There is no KiviDB connector for them: KiviDB Cloud's data integration reads Postgres and MySQL only. If you already send changes to Kafka, a consumer that applies them with the same conversion as the loader keeps KiviDB current.
Without XDR, the loader's catch-up pass does the same job in steps: it re-copies the records whose last-update time is after a given moment, using an expression filter (which Community Edition has). Deletes are not visible to a catch-up pass, so the loader also has a prune pass that removes keys whose record is gone. The runbook below uses both.