Dynamic Configuration
This feature allows you to seamlessly modify certain dynamic Aerospike configuration parameters, eliminating the need for any rolling restarts. Upon enabling this feature, any changes to dynamic configuration parameters made in the Custom Resource (CR) file are applied to the Aerospike database without needing a restart of Aerospike nodes. These dynamic changes persist after any future pod restarts, preventing any rollbacks of modifications.
Not all parameters are dynamic. Check the Configuration Reference to see which parameters are tagged as static or dynamic. Any modifications to static configuration parameters trigger a rolling restart of the Aerospike nodes to ensure proper implementation.
How to use
Activate/deactivate this feature by setting enableDynamicConfigUpdate to true or false in the Custom Resource (CR) file.
Use this feature to modify a single database parameter at a time and wait for a successful result. This approach helps avoid potential issues stemming from the specific ordering of commands, which could otherwise result in failures. For example, a partially applied configuration could cause the pod to enter an unhealthy state, requiring a manual restart. By focusing on one configuration change at a time, you can ensure smoother execution and minimize the risk of encountering command sequencing issues.
Failure handling
Internally, each configuration change is translated into an 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, the operator proceeds to the next pod.
However, there are scenarios where these commands may fail, and they are handled in two different ways:
Partial failure: If you have modified multiple parameters and some have been successfully applied while others have failed, the operator triggers a rolling restart as a fallback measure.
Full failure: If none of the configurations have been successfully applied, the operator continues attempting to apply those configurations dynamically until successful application is achieved or the user reverts those changes in the CR file.
Limitations
When the operator 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 for more information about each parameter.
| Name | Context/sub-context | Required Conditions |
|---|---|---|
microsecond-histograms | Service | This is a static configuration for the auto-enabled 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 |