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.
- The System V-style
/etc/init.d/aerospike
script for the Aerospike daemon must always be run as root. - Another alternative for running the daemon as root on some Linux systems is
systemd
. See Areospike systemd Daemon Management. - Another, more complex, alternative is to configure Aerospike itself to run as non-root. See Configure Aerospike to Run as Non-root User.
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
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
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.
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 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.