Aerospike uses a number of directories to store tools, system files, and data files. This page describes the directories in use, although they are typically managed through Aerospike tools, should you wish to manually manage these files.
This directory is created and managed by the Aerospike packages, when installed through Linux package management. It contains a number of sub-directories, some created by the tools package, others created by the server package and maintained during server run-time.
Current working directory
These directories are installed through the tools package, if in use, and are normally modified by adding and removing that package.
lib- the simple Aerospike python client used by management tools.
bin- [tools] binaries, such as aql, asadm, asbackup/asrestore, and others.
doc- tools documentation and licenses.
aqlsample files, and an example for using C with Lua.
examplesdirectory has been removed in Aerospike Tools 188.8.131.52.
- For examples please refer to the AQL documentation.
Run time directories
This directory is created by the install package to allow a place for Aerospike data files - which persist in-memory data. In standard operational configurations, the file system is not recommended, and instead data is stored on raw devices. However, for developer installation the file system is often preferred.
The System MetaData directory contains a catalog of data kept in a distributed, persistent fashion. The format for these files is JSON, for readability - it is not recommended to edit these files manually. Information about the cluster's indexes, and registered User-Defined Functions (UDFs), and other cluster-wide information is stored here.
This module was added in 184.108.40.206. It stores the eviction real-time clock for each namespace.
This module only applies to Enterprise users. Stores user permission definitions.
This module stores secondary index definitions.
This module stores per set or namespace LUT (Last Update Time) cutoffs.
This module stores User-Defined Function (UDF) definitions, the actual UDFs are stored in
For security considerations regarding System MetaData, see how to secure an SMD file.
This directory holds UDFs (and potentially other static content) which are part of the server package. They are maintained by the package manager, and are tested with the installed version of the server.
Do not modify this directory; it will not be re-created on restart.
This directory holds UDFs (and potentially other dynamic content) which are registered by administrators via cluster management tools such as aql.
It isn't recommended to directly modify files these files in production. However, in a developer environment, to speed up the development cycle, you may disable Lua caching and modify files in