FAQ - How does truncate behave during cluster changes?
truncate command scans the Aerospike primary index with the aim of removing an entire
namespace (or part of, if used with the optional last update time argument), but what is the effect on
truncate when a there are nodes leaving or joining the cluster?
If nodes return to the cluster during or after a
truncate, command has run, the SMD (System MetaData) subsystem is used to provide information on what has been
truncated. The nodes will then truncate data based on the last update time received through the
SMD subsystem (and therefore matching the truncation level of the rest of the cluster).
If the cluster is undergoing migrations, as partitions migrate across nodes, records are checked to see if they meet truncation criteria (based on the timestamp saved in the
SMD truncate file, for the specific set and/or namespace). If they do, they are discarded. In this way,
truncate is completely robust during cluster memberships changes.
When nodes are executing
truncates, incoming transactions are only executed if the last-update-time of the accessed record is not part of any truncate command (pending or completed). From an application’s perspective as soon as a truncate command is started (whether directly or through an
SMD update (including when a node joins a cluster), the would be truncated record cannot be differentiated from already truncated record and the command works as if it was instantaneous. This is possible as record accessed through any transactions are checked against the last update times stored in the
TRUNCATE MIGRATE CLUSTER CHANGE SMD