---
title: "Dynamic configuration for Aerospike on Kubernetes"
description: "Learn how to update Aerospike parameters on Kubernetes dynamically without needing database rolling restarts."
---

# Dynamic configuration for Aerospike on Kubernetes

> For the complete documentation index see: [llms.txt](https://aerospike.com/docs/llms.txt)
> 
> All documentation pages available in markdown.

This page explains how to enable dynamic configuration updates in the `AerospikeCluster` custom resource (CR). After you enable this feature, AKO can apply supported Aerospike Database configuration changes without a rolling restart, and the changes persist after future pod restarts.

::: note
Not all parameters are dynamic. Check the [Configuration Reference](https://aerospike.com/docs/database/reference/config) to see which parameters are tagged as static or dynamic. Changes to static configuration parameters trigger a rolling restart of Aerospike Database instances.

Adding a new Secret or PVC counts as a storage change and triggers a rolling cold restart, even if related to a dynamic parameter.
:::

## How to use

Enable/disable this feature by setting `enableDynamicConfigUpdate` to `true` or `false` in the Custom Resource (CR) file.

Update one database parameter at a time, and wait for the change to succeed before you make another update. This reduces the risk of partially applied configuration changes that can leave a pod in a non-functional state and require a manual restart.

## Failure handling

Internally, each configuration change is translated into an [`asadm`](https://aerospike.com/docs/database/tools/asadm) command. The commands are executed on the Aerospike database one at a time in the order they appear in the CR file, top to bottom.

If all commands succeed, AKO proceeds to the next pod.

These commands can fail in two ways:

-   Partial failure: If some parameters are applied successfully and others fail, AKO triggers a rolling restart as a fallback.
    
-   Full failure: If none of the changes are applied successfully, AKO keeps trying to apply them dynamically until the change succeeds or you revert it in the CR.
    

## Limitations

When AKO updates the Aerospike configuration dynamically, certain fields may cause a command failure if they fail to meet certain conditions.

This list is non-exhaustive and only represents the most common potential failures. See the [Configuration Reference](https://aerospike.com/docs/database/reference/config) for more information about each parameter.

| **Name** | **Context/sub-context** | **Required Conditions** |
| --- | --- | --- |
| `microsecond-histograms` | `Service` | This is a static configuration for the [auto-enabled](https://aerospike.com/docs/database/observe/latency#auto-enabled-benchmarks) histograms. |
| `connect-timeout-ms` | `Network/heartbeat` | This value must be at least `50`. It cannot be larger than one-third of the product of `heartbeat.interval` and `heartbeat.timeout`. |
| `default-ttl` | `Namespace`, `Namespace/Set` | To set a non-zero value for `default-ttl`, you must configure a non-zero `nsup-period` **or** `allow-ttl-without-nsup` to `true`. |
| `disable-write-dup-res` | `Namespace` | Only applicable for AP namespaces |
| `disallow-expunge` | `Namespace` | Only applicable for AP namespaces |
| `conflict-resolution-policy` | `Namespace` | Only applicable for AP namespaces |
| `max-throughput` | `XDR/Namespace` | Value should be a multiple of 100 |
| `transaction-queue-limit` | `XDR/Namespace` | Value should be a power of 2 |

::: note
In the XDR configuration, removing entries from list-typed fields (`ignore-bins`, `ignore-sets`, `ship-bins`, or `ship-sets`) cannot be performed dynamically. Because Aerospike does not support dropping list elements in-place, AKO must trigger a rolling restart to apply these deletions.
:::