Context
Setting up a new cluster and populating it with data is a common task for Aerospike Administrators. This article discusses methods by which this task can be completed with minimal downtime.Method
Migration from Aerospike 5.x and up- Set up Aerospike in the new location making sure to choose the latest hotfix.
- In the new cluster create and specific users, roles and quotas required.
- Set up XDR to the new cluster following guidelines found here. Configuration can be done statically or dynamically. If done dynamically add to the aerospike.conf file to ensure that the configuration persists an unexpected restart. See Note 1
- Adding the DC dynamically populate the cluster with data using the XDR rewind command as discussed here
asinfo -v "set-config:context=xdr;dc=<DC_NAME>;namespace=<NAMESPACE>;action=add;rewind=all"
- Remove any unwanted static configuration from aerospike.conf.
Migration from Aerospike 4.x and up
Aerospike 4.x in all variants is out of support. To migrate data from Aerospike 4.x a different method must be used as rewind is not available.
- Set up Aerospike in the new location making sure to choose the latest hotfix.
- In the new cluster create and specific users, roles and quotas required.
- Set up XDR to ship from the old data center to the new data center. (This must be done on all nodes of the old cluster and can be done in a rolling fashion).
- Use a 'scan and touch' UDF to touch all records within the chosen namespace. Touching the record will cause XDR to ship that record. Details on how to write a scan and touch UDF can be found here.
Migration without XDR
- Take a backup of the namespace(s) to be migrated
# Example asbackup --host NODE_IP --namespace NAMESPACE_NAME --directory backups/NAMESPACE_NAME
- Restore the data to the new cluster
# Example asrestore --host NODE_IP --directory backups/NAMESPACE_NAME --unique
Notes
Note 1: When adding a new DC via rolling restart, existing data will also be shipped when the node comes up with the XDR configuration. XDR maintains a last ship time for each DC within the system metadata directory (SMD) of each node. At start-up, the node checks the last ship time for each configured DC and ships anything later than that last ship time. When a new destination is added while the node is down, XDR ships from 'citrusleaf epoch' or, in effect, the earliest time possible. When this happens, as there is a large difference between the current time and the LUT of the last shipped record, the XDR lag will increase to a very high level. This is expected and is not an issue. In this case the subsequent rewind step is superfluousNote 2: If desired, to minimise network traffic, a backup and restore can be used for all cases to create a baseline data load in the new cluster. Rewind or scan and touch can then be used to ship the delta across to the new cluster. When doing this, XDR shipping to the new cluster should be paused by setting max-throughput or xdr-max-ship-throughput (pre Aerospike 5.x) to 0.
Note 3: By default XDR rewind does not forward records that were written by XDR. If the source has been a destination for XDR writes it may be necessary to switch on forward .