There are a number of database configuration options that can be changed while the database is running. Those options include:

For example, the following helm upgrade command changes the heartbeat timeout to 30 seconds:

$ helm upgrade mydb voltdb/voltdb       \
   --reuse-values                       \
   --set cluster.config.deployment.heartbeat.timeout=30

When dynamic configuration properties are modified, the VoltDB Operator updates the running database configuration as soon as it is notified of the change.

Many database configuration properties are static — they cannot be changed without restarting the database. Normally, this requires manually performing a voltadmin shutdown --save, reinitializing and restarting the database cluster, then restoring the final snapshot. For example, command logging cannot be turned on or off while the database is running; similarly, the number of sites per host cannot be altered on the fly.

However, you can change these properties using the helm upgrade command and the VoltDB Operator will make the changes, but not while the database is running. Instead, the Operator recognizes the changes to the configuration, marks the database as requiring a restart, and then schedules a shutdown snapshot, reinitialization, and restart of the database for later.

For example, you cannot change the number of sites per host while the database is running. But the Operator does let you change the property in Kubernetes:

$ helm upgrade mydb voltdb/voltdb       \
   --reuse-values                       \
   --set cluster.config.deployment.cluster.siteperhost=12

No action is taken immediately, since the change will require a restart and is likely to interrupt ongoing transactions. Instead, the Operator waits until you are ready to restart the cluster, which you signify by changing another property, cluster.clusterSpec.allowRestartDuringUpdate, to true:

$ helm upgrade mydb voltdb/voltdb       \
   --reuse-values                       \
   --set cluster.clusterSpec.allowRestartDuringUpdate=true

If you are sure you are ready to restart the cluster when you change the configuration property, you can set the two properties at the same time so that the change takes immediate effect:

$ helm upgrade mydb voltdb/voltdb                  \
   --reuse-values                                  \
   --set cluster.config.deployment.cluster.siteperhost=12  \
   --set cluster.clusterSpec.allowRestartDuringUpdate=true

Once allowRestartDuringUpdate is set to true, the Operator initiates the restart process, saving, shutting down, reinitializing, restarting and restoring the database automatically. Note that once the database is restarted, it is a good idea to reset allowRestartDuringUpdate to false to avoid future configuration changes triggering immediate restarts:

$ helm upgrade mydb voltdb/voltdb       \
   --reuse-values                       \
   --set cluster.clusterSpec.allowRestartDuringUpdate=false

There are properties associated with the environment that the VoltDB database runs on that you can also modify with the helm upgrade command. Most notably, you can increase the size of the cluster, using elastic scaling, by changing the cluster.clusterSpec.replicas property, as described in Section 3.3, “Resizing the Cluster with Elastic Scaling”.

Some properties affect the computing environment, such as environment variables and number of nodes. Others control the network ports assigned or features specific to Kubernetes, such as liveness and readiness. All these properties can be modified. However, they each have separate scopes that affect when the changes will go into affect.

Of particular note, pod-specific properties will not take affect until each pod restarts. If this is not a high availability cluster (that is, K=0), the Operator will wait until you to change the property cluster.clusterSpec.allowRestartDuringUpdate to true before restarting the cluster and applying the changes. The same applies for any cluster-wide properties.

However, for a K-safe cluster, the Operator can apply pod-specific changes without any downtime by performing a rolling upgrade. That is, stopping and replacing each pod in sequence. So for high availability clusters, the Operator will start applying pod-specific changes automatically via a rolling restart regardless of the cluster.clusterSpec.allowRestartDuringUpdate setting.