Which aql command I can use to drop set? ex: drop test.testset
You can use asinfo for this
asinfo -v "set-config:context=namespace;id=namespace_name;set=myset;set-delete=true;"
This will delete the set lazily through namespace supervisor cycles.
You can also check this
So. The aql utility have not any functionality like “drop namespace.set” to delete sets from namespace. I think, any client utility, working with database must overlap all functionality for operations with database objects.
Thanks for feedback. Feature request noted …
Is there anywhere to actually make a feature request? is there an Aerospike issue tracker?
How do Aerospike developers handle cleaning up data after running tests?
We have already logged (internally) the feature request above.
If you’d like to make a new feature request, you can do so in the “Feature Requests” section of our forum here.
If you’d like to report an issue, please do so in the relevant section of the forum. We will provide you with a JIRA ticket number that you can use to track your issue. There is no outside-facing Aerospike issue tracker, but you can track the resolution of your JIRA by looking at the release notes of new releases and seeing whether it’s been fixed. We will also update the relevant forum post once a release is out.
There are different ways of handling ‘cleaning up’ of data for tests. It would depend on the tests themselves…
Here are other ways other then the set-delete for handling this:
For storage-engine memory, a restart of the whole cluster does remove all the data.
For data on devices, some tests just use a file and cleaning up is as simple as removing the file, others use raw devices and then the device gets zeroized (dd) between test runs. In test environments, removing the first 1 MiB of data on a device is usually enough (that’s fast) but this is not recommended at all for production systems.
Regarding my experience on production platforms, using local SSD on GCE, the cleanest way to remove entire data is to recreate the machine entirely.
We have been facing some problems after “dd” command as some values stored on SSD by the system has been deleted, SSD can not be “remounted” after instance restart.
For tests, better use ram or ram+disk (even if it’s not perf ready), you’ll be able to remove data much faster without restarting entirely the instance.
asinfo -v “set-config:context=namespace;id=;set=;set-delete=true;”
this command deleted only data in set .
not dropped set
Please update, what is the progress on this feature?
There is no way to actually delete a set entirely without taking down the cluster and manually zero’ing the disk with dd or blkdiscard. Set-delete=true will take care of deleting the objects within the set, but actually removing it entirely is quite a task
As of Aerospike 3.12, which was released in March 2017, the feature of deleting all data in a set or namespace is now supported in the database.
Please see the following documentation: http://www.aerospike.com/docs/reference/info#truncate
Which provides the command line command that looks like: asinfo truncate:namespace=;set=;lut=
It can also be truncated from the client APIs, here is the java documentation: http://www.aerospike.com/apidocs/java/com/aerospike/client/AerospikeClient.html and scroll down to the “truncate” method.
Please note that this feature can, optionally, take a time specification. This allows you to delete records, then start inserting new records. As timestamps are used, please make certain your server clocks are well synchronized.
It works beautifully, thanks Brian/all
It works just like asinfo, and the result is the same as well–It deleted only data in set , not dropped set!
Correct, truncate will delete all of the data, but the set’s definition will remain until the node is restarted and the sets old data is no longer readable from disk. On Community this means that all wblocks that contain copies of records belonging to the truncated set have been overwritten since the truncation, on Enterprise the truncate is durable which prevents this set from being defined.