ArangoDB Production Checklist

Important steps to perform before you go live with ArangoDB deployments

The following checklist can help to understand if important steps have been performed on your production system before you go live.

Operating System

ArangoDB

  • The user root is not used to run any ArangoDB processes (if you run ArangoDB on Linux).

  • The arangod (server) process and the arangodb (Starter) process (if in use) have some form of logging enabled and logs can easily be located and inspected.

  • Memory considerations

    • If you run multiple processes (e.g. DB-Server and Coordinator) on a single machine, adjust the ARANGODB_OVERRIDE_DETECTED_TOTAL_MEMORY environment variable accordingly.
    • For versions prior to 3.8, make sure to change the --query.memory-limit query option according to the node size and workload.
    • Disable swap space to avoid slowdown which can result in servers being incorrectly detected as failed.
  • Ensure ArangoDB will be automatically restarted (e.g. by using a systemd service file). Typically you would use the Kubernetes operator or use systemd to launch the Starter.

  • If you use the Starter to deploy, you stopped - and disabled automated start of - the ArangoDB Single Instance, e.g. on Ubuntu:

    service arangodb3 stop
    update-rc.d -f arangodb3 remove
    

    On Windows in a command prompt with elevated rights:

    sc config arangodb start= disabled
    sc stop arangodb
    
  • If you have deployed a Cluster, the replication factor and minimal_replication_factor of your collections are set to a value equal or higher than 2, otherwise you run the risk of losing data in case of a node failure. See cluster startup options.

  • Disk Performance considerations

    • Verify that your storage performance is at least 100 IOPS for each volume in production mode. This is the bare minimum and it’s recommended to provide more for performance. It is probably only a concern if you use a cloud infrastructure. Note that IOPS might be allotted based on a volume size, so make sure to check your storage provider for details. Furthermore, you should be careful with burst mode guarantees as ArangoDB requires a sustainable high IOPS rate.

    • The considerations should be given to an IO bandwidth (especially considering RocksDB write-amplification which can easily be 10x or more).

  • Whenever possible use block storage. Database data is based on append operations, so filesystem which support this should be used for best performance. We would not recommend to use NFS for performance reasons, furthermore we experienced some issues with hard links required for Hot Backup.

  • Verify your Backup and restore procedures are working.

  • Consider enabling Encryption at Rest (Enterprise Edition only). Make sure to safely store any secret keys you create for this.

  • Monitor the ArangoDB provided metrics (e.g. by using Prometheus/Grafana).

Kubernetes Operator (kube-arangodb)

  • Check supported versions  for Kubernetes, operator and supported Kubernetes distributions.

  • The ReclaimPolicy  of your persistent volumes should be set to Retain to prevent volumes from premature deletion.

  • Use native networking whenever possible to reduce delays.