Context
Deleting sets doesn’t delete the associated meta data. At some point the maximum limit for sets would be breached. The following entry would be logged, indicating no more set names can be added.
WARNING (namespace): (namespace.c:580) at set names limit, can't add set-nameMethod
-
Find an unneeded set.
-
Execute the
truncatecommand for the setasinfo -v "truncate:namespace=namespaceName;set=setName" -
If secondary indexes are defined against a set to be removed, these must be deleted. They can be deleted prior to issuing the truncate command. Any remaining secondary indexes for the set will prevent the set metadata from being removed. See asadm - Manage Secondary Indexes for more information.
-
If user permissions are defined for the set to be removed, this will prevent set metadata deletion. The user permissions referencing that set must be removed. See asadm - Manage Access Control List for more information.
-
If the set is included in the XDR configuration using either
set-enable-xdrin Aerospike 4.9-, orignore-set/ship-setparameters in Aerospike 5.0+, these settings should be adjusted to ensure the set is not defined. -
Issue a cold restart on each node in a rolling fashion (waiting for migrations to complete before taking the next node down depends on the version, as the new cluster protocol introduced in version 3.13/3.14 does not require to wait for migrations to complete prior to taking the next node down).
Notes
-
If running the Community Edition, the storage would have to be erased prior to bringing the node back.
-
Be considerate of records of other sets that may be brought back as well. Deleting the whole persistent storage will avoid other deleted records, from other sets to come back. This would then require waiting for migrations to complete (to repopulate records on the empty namespace) prior to taking the next node down.