Skip to main content

Aerospike Daemon Management

/etc/init.d/aerospike​

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 likes to control exactly which processes run on your systems, be sure to whitelist /usr/bin/asd to allow it to run.

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. For a description of the kernel parameters that asd must be able to modify, see What are the OS parameters modified by Aerospike init script.

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

sudo service aerospike someArgument

The examples throughout this section show the sudo command as alternative syntax.

Start Aerospike Server​

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

To start the Aerospike database service:

/etc/init.d/aerospike start

or

sudo service aerospike start

Coldstart 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

or

sudo service aerospike coldstart

For more details, see 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

or

sudo service aerospike status
info

The status command doesn't inform you when the service port is ready, instead use the STATUS info command which will return "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

or

sudo service aerospike restart

Stop Aerospike Server​

To shut down the Aerospike Server use the stop command:

/etc/init.d/aerospike stop

or

sudo service aerospike stop
note

Aerospike flushes the data in the buffers to the disk (if data is configured to be persisted on device) when Aerospike is stopped gracefully. However, in other situations (unexpected loss of power, 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, though. For multiple nodes crashing simultaneously, different configurations can be used to avoid any data loss, including, for example, rack aware and commit-to-device (available on strong-consistency namespaces in versions 4.0 and above).

Restart Modes​

Whenever the server is restarted 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.

info

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.

note

Migrations can be tuned to go faster.

Restart Mode for In-Memory 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 will be lost.

Restart Mode for In-Memory with Persistence​

As of version 3.15.1.3, in-memory databases running the Enterprise Edition will persist their primary index in shared memory. The data will still be reloaded from storage. Once the data is reloaded, the server will automatically re-synchronize 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 for in-memory with persistence (described above). 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 index.