The mission of Aerospike Database is to be very fast, highly scalable, and extremely reliable for use in real-time big data applications. The Operations Manual explains how to create and maintain an Aerospike implementation - plan, install, configure, manage, monitor, tune and troubleshoot. This Introduction gives an overview of the content - to help you understand the various subsections of the Operations Manual and to help guide you to the right material.
This section covers how to plan and select the best hardware configuration for your application.
- Linux Capacity Planning - calculate total storage, RAM and throughput hardware requirements
- Amazon EC2 Capacity Planning - choose the right instance type for your use case
- Google Cloud Compute Capacity Planning - performance numbers factored with your application's memory requirements will help identify the right machine type.
- Server Hardware - determine what hardware to use
- Flash Storage - specialized considerations for taking advantage of flash storage
- Network - how Aerospike uses the network
This sections describes how to install Aerospike on Amazon EC2, different Linux distributions, macOS, Windows and on several cloud providers.
- Install on Linux - how to install on Red Hat, Ubuntu, Debian and other Linux distributions
- Install on macOS - using Docker Desktop on macOS
- Install on Windows - using Docker Desktop on Windows
- Install on Amazon EC2 - how to launch an Aerospike Amazon Linux AMI
- Install on Google Cloud Compute - Launch your Aerospike cluster in seconds using Google Compute Engine's Click to Deploy
- Install on Other Clouds - how to deploy on other cloud services
In Aerospike there is a single configuration file on each database node which specifies parameters for network, namespace, log and datacenter replication. For a given namespace most of the information in the configuration files will be the same.
- Amazon EC2 - recommendations for configuring port, ip address, heartbeat mode, rack awareness and other parameters
- Google Cloud Compute - recommendations for configuring network, firewall, and clusters
- Network - configure port, ip address, heartbeat mode, rack awareness and other parameters
- Namespace - configure data storage location, data retention and data replication
- Access Control - configure Access Control for user, role, and privilege creation and maintenance
- LDAP - configure using an External Authentication system
- Encryption at Rest - configure encrypting database record data on storage devices using symmetric AES-128 encryption
- Consistency - configure namespace with "strong-consistency"
- Log - configure log location and logging level, and learn use of logrotate tool
- Cross-Datacenter Replication - establish and configure Cross-Datacenter Replication (XDR) for Aerospike Enterprise Edition customers (set parameters, establish topology, configure network and specify data replication)
- Non-Root - set-up Aerospike to run as a non-root user
Aerospike management functions include starting and stopping Aerospike and XDR services, adjusting data retention policies, and managing Aerospike features like indexes, queries, scans, and UDFs.
- Aerospike Daemon - control the Aerospike Daemon with the SysV init script
- Aerospike systemd - control the Aerospike Daemon with systemd
- Consistency - add and remove nodes in strong consistency namespaces, as well as how to detect and repair unavailability
- Log Files - working with the Log File
- Storage Capacity - setting data eviction, time-to-live and defragmentation parameters
- Migrations - understanding, managing and monitoring migrations
- Sets - use asadm to set and manage parameters for a set
- Indexes - use asadm to create and manage secondary indexes
- Queries - use asadm to set and update parameters for queries across a cluster
- Scans - set configuration parameters to manage scans
- UDFs - using asadm and aql tools or a Java, C# or C client to manage UDFs
Aerospike supports upgrading a cluster or repairing a server without service downtime and without data loss.
- Aerospike - upgrade cluster software
- Hardware - upgrade cluster hardware
- Special Upgrades - special instructions for upgrading
- 4.5.1+ SMD protocol change - upgrade process for SMD protocol change in version 4.5.1+
- Storage Format Upgrade in 4.2 - upgrade process for internal storage format change
- FAQ - 4.2 upgrade - Frequently Asked Questions regarding the 4.2 upgrade
- Cluster Protocols Upgrade in 3.13 - upgrade process for full cluster protocols switch-over in version 3.13
- FAQ - 3.13 upgrade - Frequently Asked Questions regarding the 3.13 upgrade
- Network upgrade in 3.10 - upgrade path for your existing clusters, and points out the major features that these changes bring
- Stats upgrade to 3.9 - stats and benchmark migration guide for the 3.9 release
- XDR to 3.8 - upgrade XDR to version 3.8
- Aerospike 2 to 3 - upgrade from Aerospike 2 to Aerospike 3
- Community to Enterprise - upgrade from Community to Enterprise
It is important to monitor your Aerospike system in order to decrease operational response time to outage events such as hardware failure and software errors. Also, some monitoring tools (such as the Aerospike Monitoring Stack) can provide trend data to allow your operations team to effectively recognize and address future scale hurdles. Important metrics can be gathered in the areas of applications, memory, networks, storage, services and trends.
- Key Metrics - recommended metrics to use for monitoring and trending
- Latency - access latency trends from Aerospike Logs
Make sure to consult and search over the Knowledge-Base topics as a wide variety of issues and remediations are covered there.
What to do, step-by-step, to diagnose system problems. Also, specific points in the several areas listed below.
- Install - problems with installation
- Startup - problems with: ASD daemon, file descriptors in log, defrag loop, network device replacement
- Node - adjusting eviction rate to avoid an out of memory (OOM) problem
- Cluster - cluster integrity fault; check for node down; Paxos/fabric health issues after network glitch or cluster size change
- Dynamic Config - using asadm to dynamically change parameters, and a list of several common parameter settings
- Misc - fire-forget feature, transaction-pending-limit, response to stack trace, "key field too big"