The Aerospike daemon can be controlled using the System V init script
/etc/init.d/aerospike, which has the following arguments:
Linux process /usr/bin/asd
/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/aerospikescript 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:
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
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
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
restart command is equivalent to running
stop followed by
sudo service aerospike restart
Stop Aerospike Server
To shut down the Aerospike Server use the
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).
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 220.127.116.11, 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.