Skip to main content
Aerospike Vector is now live with LangChain integrationTell me more
Loading

Directory Structure

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.

/opt/aerospike​

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​

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

Tools directories​

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.
  • examples - aql sample files, and an example for using C with Lua.
    • The examples directory has been removed in Aerospike Tools 3.15.0.3.
    • For examples, see the AQL documentation.

Run time directories​

  • data

    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.

  • smd

    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.

    • 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 only applies to Enterprise strong-consistency users and was added in 4.0.0.1. It stores the roster configuration for each strong-consistency namespace.

    • security.smd

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

    • sindex.smd

      This module stores secondary index definitions.

    • truncate.smd

      This module stores per set or namespace LUT (Last Update Time) cutoffs.

    • UDF.smd

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

    • System MetaData (SMD) is secured by default.

  • sys

    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.

  • usr

    This directory holds UDFs (and potentially other dynamic content) which are registered by administrators using 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 usr/udf/lua directly.

Last updated on