Skip to content
Webinar - May 13th: How Criteo powers real-time decisions with a reduced footprintRegister now

Directory structure

This page describes the directory structure of the Aerospike Database.

Aerospike directories

Aerospike directories store tools, system files, and data files. You can manage these directories manually or with Aerospike tools.

/opt/aerospike

The /opt/aerospike directory is created and managed by the Aerospike packages when installed through Linux package management. It contains some sub-directories that are created by the tools package, and others created by the server package and maintained during server run-time.

Tools directories

Tools directories are installed through the tools package and are normally modified when that package is added or removed.

  • 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.
  • examples - aql sample files, and an example for using C with Lua.
    • For examples, see the AQL documentation.

Run time directories

Run time dirctories are the current working directories. When using Aerospike through source compilation, the run time directories are created in the current working directory instead of in /opt/aerospike.

  • data

    The /opt/aerospike directory is created by the install package to allow a place for Aerospike data files that persist in-memory data. In standard operational configurations we do not recommend the file system. Instead, data is stored on raw devices. However, for developer installation the file system is often preferred.

  • smd

    The System MetaData (smd) directory contains a catalog of data kept in a distributed, persistent fashion. The format for these files is JSON, for readability. The SMD directory stores information about the cluster’s indexes, registered User-Defined Functions (UDFs), and other cluster-wide information. We recommend that you do not edit these files manually.

    • evict.smd

      This module was added in 4.5.1.5. It stores the eviction real-time clock for each namespace.

    • roster.smd

      This module stores the roster configuration for each strong consistency-configured namespace in Enterprise Edition databases.

    • security.smd

      This module only applies to Enterprise users. Stores user permission definitions.

    • sindex.smd

      The sindex.smd module stores secondary index definitions.

    • truncate.smd

      The truncate.smd module stores per-set or namespace LUT (Last Update Time) cutoffs.

    • UDF.smd

      The UDF.smd module stores User-Defined Function (UDF) definitions. The actual UDFs are stored in the opt/aerospike/usr directory.

    • System MetaData (SMD) is secured by default.

-sys

The sys directory holds UDFs and potentially other static content that are part of the server package. They are maintained by the package manager, and tested with the installed version of the server.

Do not modify this directory; it will not be re-created on restart.

  • usr

    The usr directory holds UDFs and potentially other dynamic content that are registered by administrators using cluster management tools such as AQL.

However, to speed up the development cycle in a developer environment, you may disable Lua caching and modify files in usr/udf/lua directly.

We recommend that you do not directly modify these files in production.

Feedback

Was this page helpful?

What type of feedback are you giving?

What would you like us to know?

+Capture screenshot

Can we reach out to you?