Sites per host specifies the number of unique Volt "sites" that are created on each physical database server. The section on "Determining How Many Sites per Host" in the Using VoltDB manual explains how to choose a value for sites per host.

You set the value of sites per host using the deployment.cluster.sitesperhost property in the configuration.

K-safety defines the level of availability or durability that the database can sustain, by replicating individual partitions to multiple servers. K-safety is described in detail in the "Availability" chapter of the Using VoltDB manual.

You specify the level of K-safety that you want in the configuration using the deployment.cluster.kfactor property.

Automated snapshots provide ongoing protection against possible database failure (due to hardware or software issues) by taking periodic snapshots of the database's contents. Automated snapshots are described in detail in the section on "Scheduling Automated Snapshots" in the Using VoltDB manual.

You enable and configure automated snapshots with the deployment.snapshot property in the configuration.

Snapshot activity involves both processing and disk I/O and so may have a noticeable impact on performance (in terms of throughput and/or latency) on a very busy database. You can control the priority of snapshots activity using the deployment.systemsettings.priorities.snapshot.priority property in the configuration. The snapshot priority is an integer value between 1 and 8, with 1 being the highest priority and 8 being the lowest. The closer to 8, the longer snapshots take to complete, but the less they can affect ongoing database work.

Note that snapshot priority affects all snapshot activity, including automated snapshots, manual snapshots, and command logging snapshots.

The import and export functions let you automatically import and/or export selected data between your VoltDB database and another database or distributed service at runtime. These features are described in detail in the chapter on "Importing and Exporting Live Data" in the Using VoltDB manual.

You enable and disable import and export using the deployment.import and deployment.export properties in the configuration.

The command logging function saves a record of each transaction as it is initiated. These logs can then be "replayed" to recreate the database's last known state in case of intentional or accidental shutdown. This feature is described in detail in the chapter on "Command Logging and Recovery" in the Using VoltDB manual.

To enable and disable command logging, use the deployment.commandlog tag in the configuration.

The database servers use a "heartbeat" to verify the presence of other nodes in the cluster. If a heartbeat is not received within a specified time limit, that server is assumed to be down and the cluster reconfigures itself with the remaining nodes (assuming it is running with K-safety). This time limit is called the "heartbeat timeout" and is specified as a integer number of seconds.

For most situations, the default value for the timeout (90 seconds) is appropriate. However, if your cluster is operating in an environment that is susceptible to network fluctuations or unpredictable latency, you may want to increase the heartbeat timeout period.

You can set an alternate heartbeat timeout using the deployment.heartbeat.timeout property in the configuration.

VoltDB uses temporary tables to store intermediate table data while processing transactions. The default temp table size is 100 megabytes. This setting is appropriate for most applications. However, extremely complex queries or many updates to large records could cause the temporary space to exceed the maximum size, resulting in the transaction failing with an error.

In these unusual cases, you may need to increase the temp table size. You can specify a different size for the temp tables using the deployment.systemsettings.temptables.maxsize property in the configuration and specifying it to a whole number of megabytes. For example:

deployment:
  systemsettings:
    temptables:
      maxsize: 200

Note: since the temp tables are allocated as needed, increasing the maximum size can result in a Java out-of-memory error at runtime if the system is memory-constrained. Modifying the temp table size should be done with caution.

In general, SQL queries execute extremely quickly. But it is possible, usually by accident, to construct a query that takes an unexpectedly long time to execute. This usually happens when the query is overly complex or accesses extremely large tables without the benefit of an appropriate filter or index.

You have the option to set a query timeout limit cluster-wide, for an interactive session, or per transaction. The query limit sets a limit on the length of time any read-only query (or batch of queries in the case of the voltExecuteSQL() method in a stored procedure) is allowed to run. You specify the timeout limit in milliseconds.

To set a cluster-wide query limit you use the deployment.systemsettings.query.timeout property in the configuration. To set a limit for an interactive session in the sqlcmd utility, you use the --query-timeout flag when invoking sqlcmd. To specify a limit when invoking a specific stored procedure, you use the callProcedureWithTimeout method in place of the callProcedure method.

The cluster-wide limit is set when you initialize the database root directory. By default, the system-wide limit is 10 seconds. You can set a different timeout in the configuration. Or It can be adjusted using the voltadmin update or set command to modify the configuration settings while the database is running. If security is enabled, any user can set a lower query limit on a per session or per transaction basis. However, the user must have the ADMIN privilege to set a query limit longer than the cluster-wide setting.

The following example configuration sets a cluster-wide query timeout value of three seconds:

deployment:
  systemsettings:
    query:
      timeout: 3000

If any query or batch of queries exceeds the query timeout, the query is interrupted and an error returned to the calling application. Note that the limit is applied to read-only ad hoc queries or queries in read-only stored procedures only. In a K-Safe cluster, queries on different copies of a partition may execute at different rates. Consequently the same query may timeout in one copy of the partition but not in another. To avoid possible non-deterministic changes, VoltDB does not apply the time out limit to any queries or procedures that may modify the database contents.

VoltDB features that interact with external systems, including database replication (DR) and export, limit their activity to balance I/O latency against potentially competing with ongoing database work. These features trigger I/O based on two factors: batch size and a flush interval. In other words, data is written when enough records are received to match the batch size or, if input is sporadic, data is written when the flush interval is reached to avoid small amounts of data be held indefinitely.

There are two different settings that control how frequently data is flushed from the queues. There is a feature-specific flush setting and a system-wide minimum value. You can set different flush intervals with individual features. For example, you might set the DR flush interval to 500 milliseconds to reduce the latency of database replication, while setting the export flush interval to 4 seconds if export latency is not critical.

The system-wide minimum defines how often flush intervals are checked. So no buffers can be written more frequently than the system-wide minimum. And since the minimum check event and the feature-specific intervals may not line up exactly, actual writes occur at some incremental time after the defined interval. For example, if you set both the minimum and the DR interval at 500 milliseconds, the actual buffer writes might occur anywhere between 500 and 1000ms apart.

You set both the system-wide minimum and feature-specific intervals in the configuration using deployment.systemsettings.flushinterval and its subproperties. You set the system-wide minimum in the minimum property and you set the feature-specific intervals using the dr and export properties. All values are specified in milliseconds. For example:

deployment:
  systemsettings:
    flushinterval:
      minimum: 500
      export:
        interval: 4000
      dr:
        interval: 500

The default system-wide minimum is one second (1000). The default flush intervals for DR and export are one second (1000) and four seconds (4000), respectively.

You can avoid runaway read-only queries using the query timeout setting. But you cannot stop read-write procedures or other computational tasks, such as automated snapshots. These processes must run to completion. However, you may want to be notified when a process is blocking an execution queue for an extended period of time.

By default, VoltDB writes an informational message into the log file whenever a task runs for more than ten seconds in any of the execution sites. These tasks may be stored procedures, procedure fragments (in the case of multi-partitioned procedures), or operational tasks such as snapshot creation. You can adjust the limit when these messages are written by specifying a value, in milliseconds using the deployment.systemsettings.procedure.loginfo property in the configuration. For example, the following entry changes the threshold after which a message is written to the log to three seconds:

deployment:
  systemsettings:
    procedure:
      loginfo: 3000

Note that in a cluster, the informational message is written only to the log of the server that is hosting the affected queue, not to all server logs.

You can send mutable datatypes, most notably arrays, as arguments to a VoltDB stored procedure. By default, when this happens on a cluster with K=1 or more, VoltDB makes a copy of the array before using it in a transactional statement, to ensure that the execution of the statement is deterministic. However, copying the contents of the array consumes additional memory, which can add up if procedures are called frequently with large arrays.

The alternative, if the procedures do not modify the contents of the array, is to tell VoltDB not to copy array parameters on K-safe clusters by setting the deployment.systemsettings.procedure.copyparameters property to "false":

deployment:
  systemsettings:
    procedure:
      copyparameters: false

By default, all transactions are treated equally and executed in a first in, first out basis. However, you can enable transaction priorities where individual transactions (or groups of transactions) are given higher or lower priority.

To use transaction priorities, you must enable them in the configuration with the deployment.systemsettings.priorities property. If the property is present, priorities are enabled. Or you can explicitly enable or disable them. For example:

deployment:
  systemsettings:
    priorities:
      enabled: true

You can also set a priority for database replication and/or snapshot transactions using corresponding subproperties and specifying a priority between 1 and 8 (1 being the highest priority, 8 being the lowest):

deployment:
  systemsettings:
    priorities:
      enabled: true
      dr:
        priority: 3
      snapshot:
        priority: 6 

You can adjust the effects of prioritization by setting the maxwait property. It specifies the maximum number of milliseconds a task remains in a priority queue before it gets scheduled for execution regardless of its pioritization. This helps avoid high priority transactions essentially blocking lower priority tasks from getting scheduled. The default wait time is 1000 milliseconds. Setting maxwait to zero (0) means that prioritization is always in effect. The following example reduces the maximum wait time to half a second:

deployment:
  systemsettings:
    priorities:
      enabled: true
      maxwait: 500

Certain database operations (such as initiating snapshots) depend on synchronizing the nodes of the cluster based on their system clocks. If the clocks are too far apart, it delays the activities and interrupts normal database operations. Which is why the database checks to make sure the clocks are within a minimal level of variation (100 milliseconds) when it starts.

It is also possible for clocks to "drift" over time. So the servers also check the clock skew periodically to make sure they stay within the allowable range. You can see the latest clock skew calculation using the @Statistics system procedure with the CLOCKSKEW selector. By default, clock skew is checked every hour. You can configure the interval between checks using the deployment.systemsettings.clockskew.interval property in the database configuration, specifying the interval as an whole number of minutes. For example, the following configuration sets the clock skew interval to every half hour:

deployment:
  systemsettings:
    clockskew:
      interval: 30

The interval value can be any positive integer. If you set it to zero (0), clock skew will not be checked once the system starts.