Skip to main content

Aerospike Daemon Management


The Aerospike daemon can be controlled using the System V init script /etc/init.d/aerospike, which has the following arguments:

  • start
  • coldstart
  • status
  • restart
  • stop

Linux process /usr/bin/asd

The /etc/init.d/aerospike script launches a process named /usr/bin/asd. This is the only system process that Aerospike creates.

If your organization has controls in place to limit which processes may run on Linux systems, verify that /usr/bin/asd is on the allowlist.

Running as root or non-root

The Aerospike daemon can be run either as root or as a non-root user.

Like all system-wide daemons on Linux, running Aerospike as root ensures that the daemon can access or set the system resources it needs: kernel parameters, ports, file systems, attached devices, and more. asd must be able to modify the following kernel parameters:

kernel.shmall = 4294967296 # 4G pages = 16TB
kernel.shmmax = 1073741824 # 1GB

net.core.rmem_max = 15728640 # (15M)
net.core.wmem_max = 8388608 # (8M)

Depending on your local system settings and user privilege levels, some or all of the commands in the following instructions may need to be run with sudo.

To check your current parameter settings, run the following command:

 sysctl -a | egrep "shm|mem_max"

In addition, asd sets the maximum number of open files for the Aerospike process to 100,000 with the ulimit command. To verify that the number is set correctly, run the following command while asd is running:

cat /proc/`pgrep asd`/limits

If you are concerned about the security of giving root access to users, use sudo with the service utility to manage the daemon:

sudo service aerospike ARGS

Replace ARGS with any necessary command-line arguments.

Start Aerospike Server

For Aerospike Enterprise, start instructs the server to Fast Restart. If you're running Aerospike Community or using a namespace that isn't supported this command behaves the same as Cold Start. For more information regarding restart modes, refer to Restart Modes.

To start the Aerospike database service:

/etc/init.d/aerospike start


service aerospike start

Cold start Aerospike Server

For Aerospike Enterprise, coldstart forces the server to rebuild the in-memory index by scanning the persisted records. This may take a significant amount of time depending on the size of the data. For Aerospike Community this is the same behavior as start.

/etc/init.d/aerospike coldstart


service aerospike coldstart

For more details, refer to Cold Restart.

Get running status of Aerospike Server

To determine if the Aerospike daemon is currently running, use the status command:

/etc/init.d/aerospike status


service aerospike status

The status command doesn't inform you when the service port is ready. Instead, use the STATUS asinfo command, which returns OK when ready:

asinfo -v STATUS

Restart Aerospike Server

The restart command is equivalent to running stop followed by start:

/etc/init.d/aerospike restart


service aerospike restart

Stop Aerospike Server

To shut down the Aerospike Server use the stop command:

/etc/init.d/aerospike stop


service aerospike stop

If data is configured to be persisted on a device, Aerospike flushes the data in the buffers to the disk when Aerospike is stopped gracefully. In other situations, such as unexpected loss of power or process crash, the data present in the buffer may not make it to the device. Single node crashes with a replication-factor of 2 do not cause any data loss. For multiple nodes crashing simultaneously, you can use different configurations to avoid any data loss. For example, rack aware and commit-to-device configurations in strong consistency mode prevent data loss even in the event of multiple nodes crashing simultaneously.

Restart modes

When the server restarts gracefully, typically for a maintenance event, the namespaces may resynchronize in 3 ways depending on the namespace configuration and Aerospike version:

  • Resynchronize from other nodes.
  • Resynchronize from persisted storage and other nodes.
  • Resynchronize from memory using Fast Restart.

All resynchronization modes are performed automatically on start without operator intervention.


To maintain performance during the synchronization process (migrations), new database operation requests are handled with a higher priority. If the server is down for a long time, then the re-synchronization (migrations) may take a significant amount of time, possibly many hours depending on current activity levels, the size of the data and the speed of the network.


Migrations can be tuned to go faster.

Restart mode for in-memory databases without persistence

In-memory databases without persistence always have to re-synchronize data from the other nodes, assuming the cluster is configured with a replication-factor parameter greater than 1. If the replication factor is set to 1 then the unreplicated data previously stored in this namespace is lost.

Restart mode for in-memory databases with persistence

In-memory databases running Aerospike Enterprise Edition persist their primary index in shared memory. The data is still reloaded from storage. Once the data is reloaded, the server automatically re-synchronizes with the other servers in the cluster to get newer data updates.

Restart modes for flash storage and data in index

Databases with flash (SSD) storage have the same mode as in-memory with persistence. In Aerospike Enterprise Edition, fast restart is used.

In case of ungraceful shutdown of Aerospike or hardware restart, fast restart falls back to cold restart, reading data from flash storage to rebuild the primary index.